From owner-freebsd-arm@freebsd.org Sun Jul 10 02:27:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD62CB852AF for ; Sun, 10 Jul 2016 02:27:33 +0000 (UTC) (envelope-from freebsd-arm@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 79427185B for ; Sun, 10 Jul 2016 02:27:32 +0000 (UTC) (envelope-from freebsd-arm@herveybayaustralia.com.au) Received: from [192.168.0.177] (laptop3.herveybayaustralia.com.au [192.168.0.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 29C4162062 for ; Sun, 10 Jul 2016 12:18:18 +1000 (EST) Message-ID: <5781B068.1020107@herveybayaustralia.com.au> Date: Sun, 10 Jul 2016 12:18:16 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: Raspberry PI 3 - initial newb Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 02:27:33 -0000 Ok, so I got my hands on a RPi3 knowing that things aren't probably going to work straight off. Never worked with arm before, but trying to move towards the "future" :) rather than keep buying laptops. Haven't had much success with qemu as yet, and so thought hardware might be better and more fulfilling anyway. And they finally came in stock locally as well, so grabbed it while I could. Booted raspbian straight off to get a handle on what control should look like, and got a nice little system with a rainbow icon in the corner (?). Grabbed the output from dmesg and such and kept a copy on my laptop. My next research was to try building freebsd for arm/rpi3. Got current (10.x wouldn't do it) and built a distribution for arm64. So far so good - cross compile works fine with clang. (Remember, complete newb with cross compiling, arm, all that - worked on x86 only) I then looked at the booting process, and u-boot. Sounds like a mindfield.... fun. Also came across crotchet, which as I understand has all this scripted, but for my purposes I need to actually understand the steps rather than have the script do it for me at this stage. So not real helpful at this point - if someone could point out the steps taken would be good. So I then checked out the 10.3 rpi img from the FreeBSD downloads, and tried booting. NG. All I get is a rainbow test screen. Same with a 11-current version too. I post this here so I can get some pointers and advice on how to continue in my research and possibly getting my rpi3 to run. It looks to me that the u-boot is grabbing the wrong address and so not booting the imgs properly. Question: if the u-boot use loader to boot, then does that mean that once set there is no need to rebuild all as such - a kernel change can be initiated without hiccup? In other words, u-boot and loader stay in place, but nearly all can change around that? I'm also noting the FDT, and I have the actual dtb file for the rpi3, but how would I use it? Am I right in assuming the file is platform neutral, and so will work for linux and FreeBSD? Is there any good tutorials on using u-boot and configuring it correctly? And the main reason why I could never get qemu to work with arm was it kept asking for a kernel file - is that meant to be the u-boot file then? Cheers From owner-freebsd-arm@freebsd.org Sun Jul 10 21:30:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68F3EB83E59 for ; Sun, 10 Jul 2016 21:30:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 244941D2A for ; Sun, 10 Jul 2016 21:30:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5180 invoked from network); 10 Jul 2016 21:29:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Jul 2016 21:29:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 10 Jul 2016 17:30:45 -0400 (EDT) Received: (qmail 19291 invoked from network); 10 Jul 2016 21:30:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Jul 2016 21:30:45 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 22AF21C405F; Sun, 10 Jul 2016 14:29:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: amd64 -> armv6 [and powerpc64] -r302331 -> -r302412 re-cross-build (update): got "sh: ./make_keys: Exec format error" again for init_ketry.h in ncursesw From: Mark Millard In-Reply-To: <0394F424-484D-43B3-9C7D-8C6A8E8709F0@dsl-only.net> Date: Sun, 10 Jul 2016 14:29:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0394F424-484D-43B3-9C7D-8C6A8E8709F0@dsl-only.net> To: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Current , freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 21:30:04 -0000 On 2016-Jul-8, at 12:23 AM, Mark Millard wrote = --but with a few []'d notes added: > [Before the below cross build/update attempt I updated my amd64 from = -r302331 -> -r302412.] >=20 > Summary: It appears that WITHOUT_META_MODE=3D still needs to be forced = for cross compiles at least sometimes in order to avoid "Exec format = error". man src.conf only mentions WITHOUT_META_MODE=3D in one place: >=20 >> WITH_DIRDEPS_BUILD > . . . >> WITH_META_MODE (unless WITHOUT_META_MODE is set = explicitly) > . . . >> This must be set in the environment, make command line, = or >> /etc/src-env.conf, not /etc/src.conf. >=20 >=20 > In attempting to update my cross build (amd64 -> armv6 [or powerpc64]) = from -r302331 to -r302412 it failed with [armv6 example]: >=20 >> --- init_keytry.h --- >> sh: ./make_keys: Exec format error >> *** [init_keytry.h] Error code 126 >>=20 >> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >> .ERROR_TARGET=3D'init_keytry.h' >> = .ERROR_META_FILE=3D'/usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/= init_keytry.h.meta' >> .MAKE.LEVEL=3D'4' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> .CURDIR=3D'/usr/src/lib/ncurses/ncursesw' >> .MAKE=3D'make' >> .OBJDIR=3D'/usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw' >> .TARGETS=3D'all' >> DESTDIR=3D'/usr/obj/clang/arm.armv6/usr/src/tmp' >> LD_LIBRARY_PATH=3D'' >> MACHINE=3D'arm' >> MACHINE_ARCH=3D'armv6' >> MAKEOBJDIRPREFIX=3D'/usr/obj/clang/arm.armv6' >> MAKESYSPATH=3D'/usr/src/share/mk' >> MAKE_VERSION=3D'20160606' >> = PATH=3D'/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/clan= g/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/arm.armv6/usr/src/tm= p/legacy/bin:/usr/obj/clang/arm.armv6/usr/src/tmp/usr/sbin:/usr/obj/clang/= arm.armv6/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' >> SRCTOP=3D'/usr/src' >> OBJTOP=3D'/usr/obj/clang/arm.armv6/usr/src' >> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /root/src.configs/make.conf = /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk = /etc/src.conf /usr/src/lib/ncurses/ncursesw/Makefile = /usr/src/lib/ncurses/ncursesw/../ncurses/Makefile = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/lib/ncurses/ncursesw/../config.mk /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/lib/ncurses/ncursesw/../Makefile.inc = /usr/src/lib/ncurses/ncursesw/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' >> .PATH=3D'. /usr/src/lib/ncurses/ncursesw = /usr/src/lib/ncurses/ncursesw/../ncurses = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/base = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tty = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/widechar = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/trace = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/man' >> 1 error >=20 > again. >=20 > This was based on: >=20 >> # more = ~/sys_build_scripts.amd64-host/make_rpi2_nodebug_clang_bootstrap-amd64-hos= t.sh=20 >> kldload -n filemon && \ >> script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= $(date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host= " \ >> WITH_META_MODE=3Dyes \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/clang" \ >> make $* >=20 > and. . . >=20 >> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 >> TO_TYPE=3Darmv6 >> # >> KERNCONF=3DRPI2-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITH_CROSS_COMPILER=3D >> WITHOUT_SYSTEM_COMPILER=3D >> # >> #CPUTYPE=3Dsoft >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> WITH_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> WITHOUT_LIBSOFT=3D >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG_FILES=3D >> # >> XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >> XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >=20 > make.conf was empty. >=20 > The earlier -r302331 cross build had WITH_LIBSOFT=3D in use. -r302412 = is my first testing of WITHOUT_LIBSOFT=3D after rebuilding all ports to = avoid libsoft. [Does not apply to the powerpc64 example.] I should have mentioned the alternative of keeping WITH_META_MODE=3Dyes = but doing a cleanworld before doing a separate buildworld. This is = generally handier if one is to keep using WITH_META_MODE=3Dyes . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Jul 10 22:50:45 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA0EBB858E9 for ; Sun, 10 Jul 2016 22:50:45 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 7EB3E1444 for ; Sun, 10 Jul 2016 22:50:45 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id B787B405C61 for ; Sun, 10 Jul 2016 17:50:42 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Raspberry Pi2 odd booting problem Message-ID: <50bcb1c1-ea4d-f53f-0595-dd7df7841f70@denninger.net> Date: Sun, 10 Jul 2016 17:50:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070706090607030000000207" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 22:50:45 -0000 This is a cryptographically signed message in MIME format. --------------ms070706090607030000000207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So I'm trying to modify an existing SD card image to do something different. I imaged the card, re-wrote it onto a new card, and then mounted the FreeBSD partition. All was well doing this. Next, I did a "newfs -U /dev/da3s2a" to clear the FreeBSD partition and then wrote a *different* build back onto it using pax. Why do this rather than image the (other) card? Because it's a hell of a lot faster and you only write part of the card instead of all of it. This should work, and does on Intel-based systems without a problem. Butttttt.... not this time. /dev/ufs/rootfs is not there when the system boots and the mount of the root filesystem fails. If I plug a keyboard and monitor in and hit "?" I can see the partition and if I specify THAT as "ufs:partitionmame" the system comes up. So what's going on here? All I did to the existing format on the card was run a newfs on the UFS partition and then replace the files, which really isn't any different than what you do when you're doing a manual install on an Intel box, and suddenly what I get is non-functional -- some part of the kernel's idea of how the device tree lays out for that SD card (with the ufs partition under /dev/ufs) disappeared on me. Any ideas how this got boogered up? I can fix it of course but I'd prefer not to wait the hour for the SD card image method per-card! --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070706090607030000000207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTAyMjUwMTdaME8GCSqGSIb3DQEJBDFCBEAH HaBrKXQuBczXHL4T1zlaW29rMPxR+oHYPnRzdmpNLeJhhzxCJx9TdktyPJJuPPooNkNMl8iZ FGHFsxg9f1n5MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAZjU8QyfM XaNWNBd87kHs3bEd3CyFQV+6lQE3wpQGlsVm1/WcxUczTBxrDoE3UqMIgw2KyYLQ35nxX5P+ 1+1ord/h96JvTaTNjwV5+qpZ9gN9Jh9Z9PX0E6oChL4Rx6MGaf6aDfj4nNxfNMcE1OOB658T dA7FOwGs1CNwvcmgCK+uZaFjTo4eQ6ahIYn+Y7MynEDvslTYJuozYdTVgoYECCYRRnXEU89v H79Z5NCSGVLpfNLAmPNIxEhmmGtkV28ha1BHgxQ2EX0M7W5JeGmFkLrk/opwZ9hIlsIoIdKN 1iCz3z1xzrvB1PhXA8Uhmdtq+11KoVNR74vpTHSnXipa53gZuYIvXQr4JjpJ5QF0PkzQE2IK T9lV+411+PXTkYbWh34jjISt/RXqTdQ29nXmHb2m/oedqctgKiL4jQTezprn4+9vTL8Lk60L DiDi0/HIxPYQrAT4NkMgOq0AREY13QH9fdFY10H1fMhQQB40anyF8jLbAnY0n/kLk29He6xU /hgO9FfOTXjftpmHcHCtYVUNz0vjN0uvC4IQMbhINg/G2Z3yglqB7zO6Fi1rrZuue/jqfAlN 6LuMU4QQC/wxdicf0dHRpiUlVxLYDCLvmke3vTiTbYIEgoRVylYq84GVQhiMsFlu6cbSYytD DCX/edQ5OBH7bCs7Hu9mZcfEVi4AAAAAAAA= --------------ms070706090607030000000207-- From owner-freebsd-arm@freebsd.org Sun Jul 10 23:48:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7ECC1B838BD for ; Sun, 10 Jul 2016 23:48:56 +0000 (UTC) (envelope-from karlthane@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 38049178E for ; Sun, 10 Jul 2016 23:48:56 +0000 (UTC) (envelope-from karlthane@gmail.com) Received: by mail-io0-x230.google.com with SMTP id t74so85925011ioi.0 for ; Sun, 10 Jul 2016 16:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=99WP6DGMPI9L1kPED2vOf4xgG2bxhBq0eJ+nIpy+s0I=; b=NFq5K4jyUrrPl/y+dRIOz6dN14jlyd466FTTpCC94EpGHLNTP7OJB9JSQtf/qDpemF TX0xYIgr7rTj5xoI5e2FDur+6vblEWg1vAr9AsG8cvBFgM6ts9auBO3313X1cw/CAF24 w9A6XUrnNyNVKWC2eLMWxs13c/lhG7ELT+qwqA5KjeZBvoSV5XjqiTl4KWhq5i9RBCyb YhvYceGIwFeIvOrC5BY/bJ4mmbRgLfJoC0v0mfw14BZHYCCxeWBSRr2HZ0XdfzVdNcA1 DgfQLiEfJJeFQZRwlbXyJHyQDPU8Cfuv937iWNRv77TiISOLBXw62SkrOMEHnjAka3iy NReg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=99WP6DGMPI9L1kPED2vOf4xgG2bxhBq0eJ+nIpy+s0I=; b=AkyxJWuJRIP0nwFxZv2ynrNbsnv3csHl2PpuA5Wqfgb5NiwibfeZJFAJ4g5QmhsOo2 voAbcf5qp78YZVYdGmNX1uiDuqlTp1n+1UXEGJ5j6qcImwG/yXnlLwJbCzBP41F4cm5n HHbYZs0CPKYfh4oIir00QlqoDhdQ4xHpb9t89halhtDCc7z/k6V+GAbe4oVx7dsf4SYR 83fvP5+6+egOglL8iDIAfOHxmCrubB3T+0JZd+/UCG62Fpx6YqfIryVwXTE5XPGkJwnS 3vEfBDUU43gMkap559R60/2+JvjTwkZiqrHxBL4uKOO2E9EIs6VjLo4hLoqYWP2RbfY/ UKQw== X-Gm-Message-State: ALyK8tL4zPvOx+d6fPJ+myOVvRBVz9waBGYfLQrrRu7bFx4sUhjtrWS7EZqP/e1WB7jCnGObLhVQ4JyOA4F3OA== MIME-Version: 1.0 X-Received: by 10.107.138.212 with SMTP id c81mr5777723ioj.148.1468194535373; Sun, 10 Jul 2016 16:48:55 -0700 (PDT) Received: by 10.107.169.72 with HTTP; Sun, 10 Jul 2016 16:48:55 -0700 (PDT) Received: by 10.107.169.72 with HTTP; Sun, 10 Jul 2016 16:48:55 -0700 (PDT) In-Reply-To: References: Date: Sun, 10 Jul 2016 18:48:55 -0500 Message-ID: Subject: 11-Alpha to 11-Beta rewrite card or buildworld From: Alex Thomas To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 23:48:56 -0000 Started playing around on a Raspberry Pi 2, it has 11-Alpha5 saw that Beta1 is out. Is it better to rewrite the card and start over, or take the couple of days to do buildworld/buildkernel? From owner-freebsd-arm@freebsd.org Sun Jul 10 23:53:03 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3928B83A12 for ; Sun, 10 Jul 2016 23:53:03 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 A7FFE1A5B for ; Sun, 10 Jul 2016 23:53:03 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 5CFEA406048 for ; Sun, 10 Jul 2016 18:53:01 -0500 (CDT) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld To: freebsd-arm@freebsd.org References: From: Karl Denninger Message-ID: Date: Sun, 10 Jul 2016 18:52:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000903070204030103050707" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 23:53:03 -0000 This is a cryptographically signed message in MIME format. --------------ms000903070204030103050707 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/10/2016 18:48, Alex Thomas wrote: > Started playing around on a Raspberry Pi 2, it has 11-Alpha5 saw that B= eta1 > is out. Is it better to rewrite the card and start over, or take the co= uple > of days to do buildworld/buildkernel? > I have a cross-build setup on one of my higher-powered AMD systems, so I build the new Pi software on that. It winds up with a "nfsroot/" directory structure, and then you can rsync that over the top of the running Pi system or shut it down, pull the card, mount the card on the AMD box and rsync it over that way. Beware that you must also make sure the DTB file gets copied onto the dos partition or it may not boot, but if that happens it's easy to fix. This also is a good way to find out that the card is buggered (failing) too - I've had that happen twice, and with it mounted on the AMD machine in a USB slot (plug-in stick adapter) it actually panic'd the underlying box! Considering that it was mounted as a *data* drive and the OS itself was running off a ZFS partition (that is, not even the buffer cache was shared!) that surprised me, but it's completely repeatable.=20 Get I/O errors out of the CAM layer on 11 and there's a decent shot the box will blow up. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000903070204030103050707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTAyMzUyMzdaME8GCSqGSIb3DQEJBDFCBEAA hhYzVJx2DioJCW8Mauh9NIPyzmnoKDjfAdGDLlZOC5f6RHX0BhcMRIe1G4j3T1yqYnnsggnQ Kki8RLjU80nvMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIACFeOUC9Y 9Y8z2c4KXRoAi2+juMzXyk1oXnAiMycbJANf4UAIX1OIfwwxv2ZB7o1FhfXxgxvTmkfEaId2 LwEM49y6zQD5pFdTedHEqa5GMnrbTGcMEhrNGEVhCP0pC8ic3W+oTUth+6dX4cujnyZr6mIE +pI92qbCeR3N+PPJE1clpkfuvfsPu4EGNsurc8jG+O5ulwnakwzPRA4hQxOjy9gGYkNcuOLY SPqBWgJgBnFu4ntG0AANMk1+GCsm9bTIuNxuUBoGcHtxBXR3pD+x3Pj0JKV1WsqRwIK9e7LL +2d7OsOOfkbcxjiCFX4AGIRVIOdhIx+2Uh1qA1dsRwWYbAQoX7Eu2xRhNsZ7OVIlJD1DcwK6 DLpxNhIP96teObjnGR7rRbRc6sLTpg7PftXpyuPULIQJH7Zj23VDWo95hx1QMNfcTKhEgNlK 2DAhTCFVg5OVr32TUy0fc+xYTSLZHHGHadlM9zUxdyK1xtOrMlAyswafDRsXD3oup1x2Nf0r lJXU0XNL2/3CZm0VSQZ6h+hgk8d4ikRZAslgO/o2NxHe4I3DPIpI+y57eLB4QS/BVFagmOK4 lCQT4r5m7jsKVlDDKmBdQLi3Pe4Vh5+CbLWHCKHd3MD3RY8gDmadvHSZRT7yuoLrnrG+g8uA S2RrAjeNN9C9xxC8wu5xUfv7cIgAAAAAAAA= --------------ms000903070204030103050707-- From owner-freebsd-arm@freebsd.org Mon Jul 11 00:41:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C91CB8474D for ; Mon, 11 Jul 2016 00:41:09 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BBA41B05 for ; Mon, 11 Jul 2016 00:41:09 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 3F6336C7; Sun, 10 Jul 2016 20:41:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Raspberry Pi2 odd booting problem From: Paul Mather In-Reply-To: <50bcb1c1-ea4d-f53f-0595-dd7df7841f70@denninger.net> Date: Sun, 10 Jul 2016 20:41:00 -0400 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8FAEC6B1-62A5-4A70-A305-F01001BBE004@gromit.dlib.vt.edu> References: <50bcb1c1-ea4d-f53f-0595-dd7df7841f70@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 00:41:09 -0000 On Jul 10, 2016, at 6:50 PM, Karl Denninger wrote: > So I'm trying to modify an existing SD card image to do something > different. I imaged the card, re-wrote it onto a new card, and then > mounted the FreeBSD partition. All was well doing this. >=20 > Next, I did a "newfs -U /dev/da3s2a" to clear the FreeBSD partition = and > then wrote a *different* build back onto it using pax. Why do this > rather than image the (other) card? Because it's a hell of a lot = faster > and you only write part of the card instead of all of it. This should > work, and does on Intel-based systems without a problem. >=20 > Butttttt.... not this time. /dev/ufs/rootfs is not there when the > system boots and the mount of the root filesystem fails. If I plug a > keyboard and monitor in and hit "?" I can see the partition and if I > specify THAT as "ufs:partitionmame" the system comes up. >=20 > So what's going on here? All I did to the existing format on the card > was run a newfs on the UFS partition and then replace the files, which > really isn't any different than what you do when you're doing a manual > install on an Intel box, and suddenly what I get is non-functional -- > some part of the kernel's idea of how the device tree lays out for = that > SD card (with the ufs partition under /dev/ufs) disappeared on me. >=20 > Any ideas how this got boogered up? I can fix it of course but I'd > prefer not to wait the hour for the SD card image method per-card! It looks like you didn't label the UFS file system when you made it. = Instead of "newfs -U /dev/da3s2a" you should have used "newfs -U -L = rootfs /dev/da3s2a". You should be able to fix it easily by doing "tunefs -L rootfs /dev/..." = on the SD card. Cheers, Paul. From owner-freebsd-arm@freebsd.org Mon Jul 11 00:48:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 831ECB84ABD for ; Mon, 11 Jul 2016 00:48:38 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21B961E43 for ; Mon, 11 Jul 2016 00:48:37 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] ([85.183.171.18]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id u6B0mZ0g017926 for ; Mon, 11 Jul 2016 02:48:35 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Mon, 11 Jul 2016 02:48:29 +0200 (CEST) Message-ID: <4876c9e05d5.30c7197a@mail.schwarzes.net> In-Reply-To: References: User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Mon, 11 Jul 2016 02:48:35 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 00:48:38 -0000 On 10.07.16, Alex Thomas wrote: > Started playing around on a Raspberry Pi 2, it has 11-Alpha5 saw that Beta1 > is out. Is it better to rewrite the card and start over, or take the couple > of days to do buildworld/buildkernel? It's not a couple of days, it's ~20 hours (and ~7h more if you build the toolchain before). -asc From owner-freebsd-arm@freebsd.org Mon Jul 11 00:49:49 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAD28B84AFD for ; Mon, 11 Jul 2016 00:49:49 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 83C871E9A for ; Mon, 11 Jul 2016 00:49:49 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 182114063D8 for ; Sun, 10 Jul 2016 19:49:47 -0500 (CDT) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld To: freebsd-arm@freebsd.org References: <4876c9e05d5.30c7197a@mail.schwarzes.net> From: Karl Denninger Message-ID: Date: Sun, 10 Jul 2016 19:49:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4876c9e05d5.30c7197a@mail.schwarzes.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030503060307050105020503" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 00:49:49 -0000 This is a cryptographically signed message in MIME format. --------------ms030503060307050105020503 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/10/2016 19:48, Andreas Schwarz wrote: > On 10.07.16, Alex Thomas wrote: > >> Started playing around on a Raspberry Pi 2, it has 11-Alpha5 saw that = Beta1 >> is out. Is it better to rewrite the card and start over, or take the c= ouple >> of days to do buildworld/buildkernel? > It's not a couple of days, it's ~20 hours (and ~7h more if you build th= e=20 > toolchain before). > > -asc Or ~20 minutes with -j8 on one of my AMD machines as a cross-compile :) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030503060307050105020503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTEwMDQ5MjNaME8GCSqGSIb3DQEJBDFCBEB5 O+HoHMrk0dJ/anagP6ccIxMhIRjt/sMLVtlTkYPp2NtaBX2KoD3IJZSuui/FkUtgfDpvS8yw 6y7hrpe0CX7QMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAivVUq6uu jgHj4sk5DNXeoWkQBO34GKGYCSfMFYqAc3yFGDTJT05+2CPNI+hO3HxJu/a+Zh7Tq41vFRSk BaQI9JIhWtcTGXnSWWV3TJOWFXmSBwT5ocC9TRZHZiwJppnYbilQQrxOmAmTTm5cF3zbjl0c kqjS28rSCIfpGoNbHT0EjXhALeZ5yEUM9UTbqs2YVRN5e/uhC0i7+h5mWksjlHXf15QY6ff0 JiRmWuzBdB3GnOwdfpHEmP6X9Q68x1e/K0MPMpQSYGpFcg+LtiZtFGpKYabsODCJu2eCDNEt bjSrvBbEmzry79kWgiUh4nqWisnP75rxXwg7rzhvXh5DPF4eGmqoAserQdbcWhoHOjMs5lkB Yzo1hlk6puA4zIpT5BOOBm4DuXJY7vI6vREjLonIJuzsBx0+4oGsNY5V9aAszIeXwhmQjTBY k9u1kHE29C8HCms/NF7L5b1kwAz9h/hrBVP6RCgnj/hJgcbT+58jp/2z9a71Jh0mPmP7BZml sriqJAt3/47NA+wAsNJ1DvxrK+MAx2UzXot/De5uXmztbYtAEyWz5DcaFoqq9xwVqUmRdFjR TIS69bivVGF98K5GTjFirdLCjRf4vZgUY8+jkaXOGbp5kn92BHNTgJQDyitsKdUFw52TPt1K 3bRFfVNZreG94yJU6TK81D47RQcAAAAAAAA= --------------ms030503060307050105020503-- From owner-freebsd-arm@freebsd.org Mon Jul 11 01:01:53 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B0B2B8514B for ; Mon, 11 Jul 2016 01:01:53 +0000 (UTC) (envelope-from karlthane@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13278160A for ; Mon, 11 Jul 2016 01:01:53 +0000 (UTC) (envelope-from karlthane@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id h190so50162431ith.1 for ; Sun, 10 Jul 2016 18:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=nGldpjV9uY6qPjqH26e/f0RNDYpiQGBf7U8X2dokcF0=; b=ncXy3YM3MXbl5GPPODKbuiBLvhmqWehJE5bFJmRJuftWwagy5zh135KOQyPGR8CmIy hT1TLu9tkUBgcxitxf7wiqSSDmqTCYmuAUkEGLx6/5SRiMONwaPZ09qXPzPlehz/tjxn qz4sLg5MLtsn93osMoHQGIAfwqXGlg8yis20zmIwF33BH+FwQXMkM/bHdvXGvgWd7+QK oM0210RBEge7lELAKkatM69UCm0JpgkZaROX4i8NOI8aD6INHRstaaVA0mv5o9gg0asw +yaxYcEZKFZhUjbpYxS+4AJ8Ogw9OI8dElT9dRrN0b/KLaK0ynLIFhTXIbr3Ab3zwXK4 GPFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=nGldpjV9uY6qPjqH26e/f0RNDYpiQGBf7U8X2dokcF0=; b=mMVaNQOUbs/324Px5DryYKYuRK3dj85dBxTGnImxCw7fLPcPYbIsrKo6SrplvQh1X4 FQw/PGArhJ9QjhgPTKBdjXSAnTDAa9iOEI22UM073AUR1gGkeOGxwsJ95PR6zhZ+HYLk aennY7p5yq0aDVwvBzSEzm67r+Cx0VHYfxdq2/9ccEta50y15blPEslE3dMUYwzPhSVE XFFpocFdpuoyPf3retEvZ0DQJWiJZu5cW2ctptXEc1BwAP5QJy9ECmHHwq5AxxvyMpHm Y7M1wdiolM65/KFPknI3ASp7+XA0cPwi3aMAtLHrPzgQZxfTO/OrRj0hsblYJ3z7TOOD KzVQ== X-Gm-Message-State: ALyK8tJGYgRdMYJsEfMGB31SUCZPlRxKNuW0AOmTV3mmQj/yzYi030u59IJ3GL7wEVJjifbm/53VrCbbngVN+w== MIME-Version: 1.0 X-Received: by 10.36.153.66 with SMTP id a63mr13018924ite.73.1468198912210; Sun, 10 Jul 2016 18:01:52 -0700 (PDT) Received: by 10.107.169.72 with HTTP; Sun, 10 Jul 2016 18:01:52 -0700 (PDT) Received: by 10.107.169.72 with HTTP; Sun, 10 Jul 2016 18:01:52 -0700 (PDT) In-Reply-To: <4876c9e05d5.30c7197a@mail.schwarzes.net> References: <4876c9e05d5.30c7197a@mail.schwarzes.net> Date: Sun, 10 Jul 2016 20:01:52 -0500 Message-ID: Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld From: Alex Thomas To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 01:01:53 -0000 On Jul 10, 2016 7:48 PM, "Andreas Schwarz" wrote: > > On 10.07.16, Alex Thomas wrote: > > > Started playing around on a Raspberry Pi 2, it has 11-Alpha5 saw that Beta1 > > is out. Is it better to rewrite the card and start over, or take the couple > > of days to do buildworld/buildkernel? > > It's not a couple of days, it's ~20 hours (and ~7h more if you build the > toolchain before). > > -asc > I remember building Gentoo on an AMD K6II and it basically taking all weekend, so that is why I figured couple of days. From owner-freebsd-arm@freebsd.org Mon Jul 11 05:08:05 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 625D9B9189F for ; Mon, 11 Jul 2016 05:08:05 +0000 (UTC) (envelope-from russ.haley@gmail.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 174DA1AEB for ; Mon, 11 Jul 2016 05:08:05 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-io0-x236.google.com with SMTP id t74so89813601ioi.0 for ; Sun, 10 Jul 2016 22:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to; bh=ui/5tOzdrb3HxCfmOugmhP8KH1c5fpC61FtEKs//pmo=; b=SvKfaPoihC9eJoTa6+Bbh+0SqFa/TBpTbdv+9trPngJ+kdlZYnw+/kidzRKtpbZuAc RN4fI+c4nNr5vdopCx307U/eTIN7GjQWgMyeep8+0FydaqxDW4m/0891QwrSqL2bomyQ PBZIIl6XqqFysUStQnnJKg3JEN3oRGzOFuDnsS1Vg9aILUXd83hHcbchS1jJDOXpP7GE sIvAiX/oVDbTHelsvJeEm3c0dw1dZB1TuoX8DRiOOzax+A9cgPb8PbGu1e1IcWKlToo2 ey3zvgbe/AYxjdS3PdnyUUlMEEcpUPZjSM9UGkWtwRit/Lo9ZLyuSXF5vronKBpvbnNe FIHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to; bh=ui/5tOzdrb3HxCfmOugmhP8KH1c5fpC61FtEKs//pmo=; b=GhG3fchhZXZws5EU1B5MMXikKHL397JOwrj0Vzh/4jQXRckXrseKhBHhbYfR4gimf8 mtvqMSg3zJPcMLAsDJBrl6ajeqTZyV82bSZPiUpcUOiDXsVlfAf3OBP6qnBDz7RkB0M4 xkvajTX/pr30yDNgTH3xbLmhTMITPGuUgT1EUN9F1BfcGpqKMic72//H9O7LX/6sihPj pJ4m2KYPSuH74mE3JkOhawwLqe2n8QpE9P9WiSfNhRosMSWVPqXXWuooDB+H4miP43Ue UDuuopoQNJdGoLuiA2qq2t9YnvBqM//dpt3jCuYwBQsSbrCPNKEWfLA6vQIGs5zTFyhJ Ffig== X-Gm-Message-State: ALyK8tKL8c0YcCLd4RpFhpiE73l70f9EgzYG+VcRWpASRtI68KA+Gp0/xrdH0uIp4o6tbQ== X-Received: by 10.107.138.101 with SMTP id m98mr9813542iod.91.1468213684430; Sun, 10 Jul 2016 22:08:04 -0700 (PDT) Received: from [127.0.0.1] ([207.228.78.160]) by smtp.gmail.com with ESMTPSA id h128sm6837561ita.19.2016.07.10.22.08.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 10 Jul 2016 22:08:03 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160711050802.4743251.48194.8248@gmail.com> Date: Sun, 10 Jul 2016 22:08:02 -0700 Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld From: Russell Haley In-Reply-To: References: <4876c9e05d5.30c7197a@mail.schwarzes.net> To: Alex Thomas , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 05:08:05 -0000 Sorry about the top post.=C2=A0 If your not trying to learn about the build process and=E2=80=8E you don't = have a custom build requirement, why not use a prebuilt image move on to va= lidating the running OS instead of repeating what the build server does? I would think there is more value in finding anomalies in your favorite app= lications. From my understanding there have been big changes to the fundame= ntals of the OS (i.e hard float, compiler upgrades, byte alignments etc).= =C2=A0 Russ Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Koodo=C2=A0network. =C2=A0 Original Message =C2=A0 From: Alex Thomas Sent: Sunday, July 10, 2016 6:01 PM To: freebsd-arm@freebsd.org Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld On Jul 10, 2016 7:48 PM, "Andreas Schwarz" wrote: > > On 10.07.16, Alex Thomas wrote: > > > Started playing around on a Raspberry Pi 2, it has 11-Alpha5 saw that Beta1 > > is out. Is it better to rewrite the card and start over, or take the couple > > of days to do buildworld/buildkernel? > > It's not a couple of days, it's ~20 hours (and ~7h more if you build the > toolchain before). > > -asc > I remember building Gentoo on an AMD K6II and it basically taking all weekend, so that is why I figured couple of days. _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Jul 11 10:06:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91C0AB84C44 for ; Mon, 11 Jul 2016 10:06:59 +0000 (UTC) (envelope-from no-reply@x59.vip.6pm-coupon.com) Received: from x59.vip.6pm-coupon.com (x59.vip.6pm-coupon.com [104.148.25.59]) by mx1.freebsd.org (Postfix) with ESMTP id 7B80C1FD6 for ; Mon, 11 Jul 2016 10:06:59 +0000 (UTC) (envelope-from no-reply@x59.vip.6pm-coupon.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=6pm-coupon; d=x59.vip.6pm-coupon.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=no-reply@x59.vip.6pm-coupon.com; bh=/Spp5My1eQ2RL3nAKM3t1WMRuq8=; b=nC0KVxtjk4WOSEugA3Xd3O6vXARlsnSc+7VN3IbnRr30FEoUL/7u5TE66uUzQaqbW0cpQR7Am43r +RmlYajdYcMa+61nVnxoMy370jypZ5aWp2Xm31YpIzfQ+DJTlbEMShzYkIJ/2Hb5jxHiMV9mspwg iuOziPfVYb503vQr2LI= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=6pm-coupon; d=x59.vip.6pm-coupon.com; b=kQ3Zno7b/t+PGqLiIlgMQuj/C/Pf4bQ6yiIqbbN2Bp5MXqePJFA9h/H+2dItgblsVAeP0txPKoD/ qV9FN29Lr6W/IHiAhmR03Q476xRxzjirC3e00HlpmHc4Bnh85LmE9BXC5YUP1W5pFRfyoTxTKu8R 70QZiQJADpeyvWL0zv0=; From: "Ray.Ban Sunglasses" To: freebsd-arm@freebsd.org Date: 11 Jul 2016 17:46:38 +0800 Subject: No Joke:Your special offer from Factory Direct Sale587 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 10:06:59 -0000 From owner-freebsd-arm@freebsd.org Mon Jul 11 12:51:54 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F327B91FE9 for ; Mon, 11 Jul 2016 12:51:54 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C56613D4 for ; Mon, 11 Jul 2016 12:51:54 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 57EAB758; Mon, 11 Jul 2016 08:51:52 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld From: Paul Mather In-Reply-To: <20160711050802.4743251.48194.8248@gmail.com> Date: Mon, 11 Jul 2016 08:51:52 -0400 Cc: Alex Thomas , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> References: <4876c9e05d5.30c7197a@mail.schwarzes.net> <20160711050802.4743251.48194.8248@gmail.com> To: Russell Haley X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:51:54 -0000 On Jul 11, 2016, at 1:08 AM, Russell Haley wrote: > Sorry about the top post.=20 >=20 > If your not trying to learn about the build process and=E2=80=8E you = don't have a custom build requirement, why not use a prebuilt image move = on to validating the running OS instead of repeating what the build = server does? >=20 > I would think there is more value in finding anomalies in your = favorite applications. =46rom my understanding there have been big = changes to the fundamentals of the OS (i.e hard float, compiler = upgrades, byte alignments etc). Speaking for myself, I just find the build{world,kernel} + = install{kernel,world} + mergemaster sequence of updating the system a = much more ingrained and normal method of doing things. It seems = "natural" to me to update my FreeBSD/arm systems the same way I update = my FreeBSD/amd64 systems. Besides, if I overwrote my SD card with a new install image, I'd lose = all my settings (e.g., users, custom /usr/local/etc/pkg/repos/ = repository, swap partition on SD card, /etc/fstab changes to make /tmp = bigger[*], etc.). It's more natural for me to use the standard update = technique than redo those changes from scratch each time I update the = OS. (I'm using SaltStack to configure more and more, but even getting a = minion set up means it's easier to update the standard way than start = with a fresh install image and have to re-bootstrap SaltStack.) Cheers, Paul. [*] The default /tmp size in the install images seems too small to build = the OS natively on FreeBSD/arm nowadays. Plus, I have to have swap = enabled to be able to do a successful installworld. > =20 >=20 > Russ >=20 > Sent from my BlackBerry 10 smartphone on the Koodo network. > Original Message =20 > From: Alex Thomas > Sent: Sunday, July 10, 2016 6:01 PM > To: freebsd-arm@freebsd.org > Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld >=20 > On Jul 10, 2016 7:48 PM, "Andreas Schwarz" = wrote: >>=20 >> On 10.07.16, Alex Thomas wrote: >>=20 >>> Started playing around on a Raspberry Pi 2, it has 11-Alpha5 saw = that > Beta1 >>> is out. Is it better to rewrite the card and start over, or take the > couple >>> of days to do buildworld/buildkernel? >>=20 >> It's not a couple of days, it's ~20 hours (and ~7h more if you build = the >> toolchain before). >>=20 >> -asc >>=20 >=20 > I remember building Gentoo on an AMD K6II and it basically taking all > weekend, so that is why I figured couple of days. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Jul 11 13:25:05 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FDFBB83B89 for ; Mon, 11 Jul 2016 13:25:05 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 539541BEB for ; Mon, 11 Jul 2016 13:25:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 9129D408B53 for ; Mon, 11 Jul 2016 08:25:02 -0500 (CDT) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld To: freebsd-arm@freebsd.org References: <4876c9e05d5.30c7197a@mail.schwarzes.net> <20160711050802.4743251.48194.8248@gmail.com> <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> From: Karl Denninger Message-ID: Date: Mon, 11 Jul 2016 08:24:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070708000807070109040202" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:25:05 -0000 This is a cryptographically signed message in MIME format. --------------ms070708000807070109040202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/11/2016 07:51, Paul Mather wrote: > On Jul 11, 2016, at 1:08 AM, Russell Haley wrote= : > >> Sorry about the top post.=20 >> >> If your not trying to learn about the build process and=E2=80=8E you d= on't have a custom build requirement, why not use a prebuilt image move o= n to validating the running OS instead of repeating what the build server= does? >> >> I would think there is more value in finding anomalies in your favorit= e applications. From my understanding there have been big changes to the = fundamentals of the OS (i.e hard float, compiler upgrades, byte alignment= s etc). > > Speaking for myself, I just find the build{world,kernel} + install{kern= el,world} + mergemaster sequence of updating the system a much more ingra= ined and normal method of doing things. It seems "natural" to me to upda= te my FreeBSD/arm systems the same way I update my FreeBSD/amd64 systems.= > > Besides, if I overwrote my SD card with a new install image, I'd lose a= ll my settings (e.g., users, custom /usr/local/etc/pkg/repos/ repository,= swap partition on SD card, /etc/fstab changes to make /tmp bigger[*], et= c.). It's more natural for me to use the standard update technique than = redo those changes from scratch each time I update the OS. (I'm using Sa= ltStack to configure more and more, but even getting a minion set up mean= s it's easier to update the standard way than start with a fresh install = image and have to re-bootstrap SaltStack.) > > Cheers, > > Paul. > The reason I do the "crossbuild" + "rsync" thing is that it gives me the ability to do the buildworld/buildkernel/installworld/installkernel paradigm to a "holding directory" on a very fast machine, then rsync the results. (Mounting the holding directory via NFS works as well but I see no real advantage to that over using rsync) That means I don't lose anything I did to the machine after install (e.g. users, etc) and in addition I can put local patches on the source tree if required, but I still get a reasonable build time. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070708000807070109040202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExMzI0MzZaME8GCSqGSIb3DQEJBDFCBEAp t+vBGU91NwbMYsA/dTX8cRGyvq6svVLsDjeS59mZyzv/98ZRbzcQGyYATK8Nvfi2dHLbLVMN 1mA4yM0vT0bLMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAszFPejk6 Z/kYKm6R72SyATygVMg5K9kqMZ6k8GNAtVF/td9nrVb4P81Yecwi5Hf/UaTqxgDAlCsu++gd 46D3EP3HZ4XDA6nKKyddf6q9+jiq4DHHqLeSmtNGL2u0LA/RZ03kCLm/cthDrN2NNXYCHkhR 4H+QNxPzKEHsDTC7XVXqgNYRGTxq0rXGdFsx0DKNU2uqearV8tzXdh5U2TJdp70msPMBV6hJ QJhpRXHBMEH0jOJKWHT+QIFVYVzoLJ+FOMVOzzokJFdxovqwnHCQ4gWlZm29szk+CcXXJKTR I7M7DXNUNfsjluwrBo6GiS8D5D2vrUVDI5wd1cLYSEhi7V0WZqZlHqAlpRTKbp0gGAXvqzGI SLhK3+8umFwE7DTuKsRKRAFQ9tDzLwUiRsn0nzt6QkO4mFaeo9vKCOcpofGOc9+zVpQ1jv0T AmCOvLF6eUYrkZ7Wt7Nmf1KJHaA5f8ExaJkFpY4EXr3lH2Fjduzp+8gxXFY9NoVLEdD5xDu7 hk6x+6c/UNf9bF2wTmwgqUGwwhvoNEXtIHfXmFAN1NjEaAfI27zCCGGl8rRv0pjPUfgzJHwf 9td3uasKdKfFv5wR1gWrLRtZPVp+gAdTkS4o1ku+ghQ7pWH8Gpsl9ckqJHSaGqJ9u5VUMd2B zfx7huUfA6lBfw3n6NUCvdhKHbkAAAAAAAA= --------------ms070708000807070109040202-- From owner-freebsd-arm@freebsd.org Mon Jul 11 13:54:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0463BB84E6F for ; Mon, 11 Jul 2016 13:54:16 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6AD216EE for ; Mon, 11 Jul 2016 13:54:15 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 465D5775; Mon, 11 Jul 2016 09:54:14 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld From: Paul Mather In-Reply-To: Date: Mon, 11 Jul 2016 09:54:13 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4876c9e05d5.30c7197a@mail.schwarzes.net> <20160711050802.4743251.48194.8248@gmail.com> <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:54:16 -0000 On Jul 11, 2016, at 9:24 AM, Karl Denninger wrote: > On 7/11/2016 07:51, Paul Mather wrote: >> On Jul 11, 2016, at 1:08 AM, Russell Haley = wrote: >>=20 >>> Sorry about the top post.=20 >>>=20 >>> If your not trying to learn about the build process and=E2=80=8E you = don't have a custom build requirement, why not use a prebuilt image move = on to validating the running OS instead of repeating what the build = server does? >>>=20 >>> I would think there is more value in finding anomalies in your = favorite applications. =46rom my understanding there have been big = changes to the fundamentals of the OS (i.e hard float, compiler = upgrades, byte alignments etc). >>=20 >> Speaking for myself, I just find the build{world,kernel} + = install{kernel,world} + mergemaster sequence of updating the system a = much more ingrained and normal method of doing things. It seems = "natural" to me to update my FreeBSD/arm systems the same way I update = my FreeBSD/amd64 systems. >>=20 >> Besides, if I overwrote my SD card with a new install image, I'd lose = all my settings (e.g., users, custom /usr/local/etc/pkg/repos/ = repository, swap partition on SD card, /etc/fstab changes to make /tmp = bigger[*], etc.). It's more natural for me to use the standard update = technique than redo those changes from scratch each time I update the = OS. (I'm using SaltStack to configure more and more, but even getting a = minion set up means it's easier to update the standard way than start = with a fresh install image and have to re-bootstrap SaltStack.) >>=20 >> Cheers, >>=20 >> Paul. >>=20 > The reason I do the "crossbuild" + "rsync" thing is that it gives me = the > ability to do the buildworld/buildkernel/installworld/installkernel > paradigm to a "holding directory" on a very fast machine, then rsync = the > results. (Mounting the holding directory via NFS works as well but I > see no real advantage to that over using rsync) >=20 > That means I don't lose anything I did to the machine after install > (e.g. users, etc) and in addition I can put local patches on the = source > tree if required, but I still get a reasonable build time. I've successfully done cross building on a fast FreeBSD/amd64 machine = but have always had to move the SD card physically to that machine to do = the install{kernel,world} + mergemaster phase. The reason for this is = when I tried rsyncing to copy to the FreeBSD/arm system the rsync = application would not handle file flags (noschg, etc.) properly and = rsyncing would fail, even though I'd built it with the file flags patch = enabled. Going by what you say above, that appears to work properly = now, so I may re-try that. I've also not had luck cross building on a fast FreeBSD/amd64 system and = then trying to install on FreeBSD/arm by NFS mounting the src and obj = crossbuild directories and doing an install{kernel,world} + mergemaster = on the FreeBSD/arm system. When I posted about this I believe the = reason is that the build systems gets confused about the change in build = and install paths. There may also be something about the build/install = toolchain, too. I forget. I just remember it didn't seem to work for = me when I tried it and asked about it on this mailing list. :-) If someone were to do a little "fastest way to update your FreeBSD/arm = OS without having to move the SD card physically to the build system" = HOWTO, that would be great. ;-) Cheers, Paul. From owner-freebsd-arm@freebsd.org Mon Jul 11 14:00:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38409B855EE for ; Mon, 11 Jul 2016 14:00:37 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 D4A6A1BA3 for ; Mon, 11 Jul 2016 14:00:36 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id B7D5F408E75 for ; Mon, 11 Jul 2016 09:00:35 -0500 (CDT) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld References: <4876c9e05d5.30c7197a@mail.schwarzes.net> <20160711050802.4743251.48194.8248@gmail.com> <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> To: freebsd-arm@freebsd.org From: Karl Denninger Message-ID: Date: Mon, 11 Jul 2016 09:00:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080804060206000804020504" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 14:00:37 -0000 This is a cryptographically signed message in MIME format. --------------ms080804060206000804020504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/11/2016 08:54, Paul Mather wrote: > On Jul 11, 2016, at 9:24 AM, Karl Denninger wrote:= > >> On 7/11/2016 07:51, Paul Mather wrote: >>> On Jul 11, 2016, at 1:08 AM, Russell Haley wro= te: >>> >>>> Sorry about the top post.=20 >>>> >>>> If your not trying to learn about the build process and=E2=80=8E you= don't have a custom build requirement, why not use a prebuilt image move= on to validating the running OS instead of repeating what the build serv= er does? >>>> >>>> I would think there is more value in finding anomalies in your favor= ite applications. From my understanding there have been big changes to th= e fundamentals of the OS (i.e hard float, compiler upgrades, byte alignme= nts etc). >>> Speaking for myself, I just find the build{world,kernel} + install{ke= rnel,world} + mergemaster sequence of updating the system a much more ing= rained and normal method of doing things. It seems "natural" to me to up= date my FreeBSD/arm systems the same way I update my FreeBSD/amd64 system= s. >>> >>> Besides, if I overwrote my SD card with a new install image, I'd lose= all my settings (e.g., users, custom /usr/local/etc/pkg/repos/ repositor= y, swap partition on SD card, /etc/fstab changes to make /tmp bigger[*], = etc.). It's more natural for me to use the standard update technique tha= n redo those changes from scratch each time I update the OS. (I'm using = SaltStack to configure more and more, but even getting a minion set up me= ans it's easier to update the standard way than start with a fresh instal= l image and have to re-bootstrap SaltStack.) >>> >>> Cheers, >>> >>> Paul. >>> >> The reason I do the "crossbuild" + "rsync" thing is that it gives me t= he >> ability to do the buildworld/buildkernel/installworld/installkernel >> paradigm to a "holding directory" on a very fast machine, then rsync t= he >> results. (Mounting the holding directory via NFS works as well but I >> see no real advantage to that over using rsync) >> >> That means I don't lose anything I did to the machine after install >> (e.g. users, etc) and in addition I can put local patches on the sourc= e >> tree if required, but I still get a reasonable build time. > I've successfully done cross building on a fast FreeBSD/amd64 machine b= ut have always had to move the SD card physically to that machine to do t= he install{kernel,world} + mergemaster phase. The reason for this is whe= n I tried rsyncing to copy to the FreeBSD/arm system the rsync applicatio= n would not handle file flags (noschg, etc.) properly and rsyncing would = fail, even though I'd built it with the file flags patch enabled. Going = by what you say above, that appears to work properly now, so I may re-try= that. > > I've also not had luck cross building on a fast FreeBSD/amd64 system an= d then trying to install on FreeBSD/arm by NFS mounting the src and obj c= rossbuild directories and doing an install{kernel,world} + mergemaster on= the FreeBSD/arm system. When I posted about this I believe the reason i= s that the build systems gets confused about the change in build and inst= all paths. There may also be something about the build/install toolchain= , too. I forget. I just remember it didn't seem to work for me when I t= ried it and asked about it on this mailing list. :-) > > If someone were to do a little "fastest way to update your FreeBSD/arm = OS without having to move the SD card physically to the build system" HOW= TO, that would be great. ;-) > > Cheers, > > Paul. You do need to tell rsync to handle the schg flags -- for example: rsync -av --force-schange --fileflags -I -e 'ssh -p ' 'karl@newfs:/pics/CrossBuild/nfsroot/' / -p is for those who run sshd on a non-standard port (which I do to reduce the number of crazies trying to connect to my boxes and thus the noise in the nightly security reports.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080804060206000804020504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExNDAwMDlaME8GCSqGSIb3DQEJBDFCBEBn oiYCInN6bHI6SrTXx7aN6HsTWIC0naE6275oC5oLyhRaiezvBc5bjST1tWjmdy8N8QgwoYWD He0kyULtTvGjMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAerBLLwuB RFjq1zSKOepCTcqSE2D1HgK47qciTV3sdlnVfA4KIyw8FyhSiLiua+XraFxRXhq3PT9oQzqR eDsaW2j7ZCtb704Ez6fPx4U2fJFPD+PQBlpcSUAxbxonV9wGj5eIg3HrfKA1SerSTdHELUmY lo8a9i8aw6/SLxFrjv+OpfQ/qt1vKw9ZvFvtC5n+X7ml9uJUqTLqyFnAb9kSHwU0lo0RhbEY fThBknRxeRteoBBnG9TlNAqzknyJ4aLrA2KrqwYwabUs1QcttVFxvk10NLJct7fGeUo5nr5Z eJBAOy/6XUkKHNc0JwL4XdadZ4+o57A1UXontNwDgh0MRXroRLTF6uu1vTNKY+D7+eGC6acD GBfWeXp8sfKHsTE88KLGlDi+XKhv9X0Z7Y/ZffAbR42atBCPA5spEsgeomsY3JP9X39CYo5R n9vMJWKIYtOt0vS1nUHWyTrQDqsR02w2yxDzwKopOYE293EIulx5c3rZYm9AS6uq/HGxVVuY ueQFUX71ZJa1Q7vY2cb/x7QYfYPaMJlZUoHd17UERq/kbsM4snKNebE2p3Ri/npoTBUAjXIw OFOwuNd2gdnq1/ADfpze4v2MOHK+mKol+tfYiKtH5evNvI9EZbdn1twybdqHJidmm/wBJSlL t9sV8wUw/jnk7itdVHsgwhoh0jMAAAAAAAA= --------------ms080804060206000804020504-- From owner-freebsd-arm@freebsd.org Mon Jul 11 15:20:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D308B920D4 for ; Mon, 11 Jul 2016 15:20:35 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1600D1AC4 for ; Mon, 11 Jul 2016 15:20:34 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id D8E8278D; Mon, 11 Jul 2016 11:20:33 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld From: Paul Mather In-Reply-To: Date: Mon, 11 Jul 2016 11:20:33 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0979D126-85A1-4AD2-B99D-C0D1272E5A16@gromit.dlib.vt.edu> References: <4876c9e05d5.30c7197a@mail.schwarzes.net> <20160711050802.4743251.48194.8248@gmail.com> <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 15:20:35 -0000 On Jul 11, 2016, at 10:00 AM, Karl Denninger wrote: > On 7/11/2016 08:54, Paul Mather wrote: >> On Jul 11, 2016, at 9:24 AM, Karl Denninger = wrote: >>=20 >>> On 7/11/2016 07:51, Paul Mather wrote: >>>> On Jul 11, 2016, at 1:08 AM, Russell Haley = wrote: >>>>=20 >>>>> Sorry about the top post.=20 >>>>>=20 >>>>> If your not trying to learn about the build process and=E2=80=8E = you don't have a custom build requirement, why not use a prebuilt image = move on to validating the running OS instead of repeating what the build = server does? >>>>>=20 >>>>> I would think there is more value in finding anomalies in your = favorite applications. =46rom my understanding there have been big = changes to the fundamentals of the OS (i.e hard float, compiler = upgrades, byte alignments etc). >>>> Speaking for myself, I just find the build{world,kernel} + = install{kernel,world} + mergemaster sequence of updating the system a = much more ingrained and normal method of doing things. It seems = "natural" to me to update my FreeBSD/arm systems the same way I update = my FreeBSD/amd64 systems. >>>>=20 >>>> Besides, if I overwrote my SD card with a new install image, I'd = lose all my settings (e.g., users, custom /usr/local/etc/pkg/repos/ = repository, swap partition on SD card, /etc/fstab changes to make /tmp = bigger[*], etc.). It's more natural for me to use the standard update = technique than redo those changes from scratch each time I update the = OS. (I'm using SaltStack to configure more and more, but even getting a = minion set up means it's easier to update the standard way than start = with a fresh install image and have to re-bootstrap SaltStack.) >>>>=20 >>>> Cheers, >>>>=20 >>>> Paul. >>>>=20 >>> The reason I do the "crossbuild" + "rsync" thing is that it gives me = the >>> ability to do the buildworld/buildkernel/installworld/installkernel >>> paradigm to a "holding directory" on a very fast machine, then rsync = the >>> results. (Mounting the holding directory via NFS works as well but = I >>> see no real advantage to that over using rsync) >>>=20 >>> That means I don't lose anything I did to the machine after install >>> (e.g. users, etc) and in addition I can put local patches on the = source >>> tree if required, but I still get a reasonable build time. >> I've successfully done cross building on a fast FreeBSD/amd64 machine = but have always had to move the SD card physically to that machine to do = the install{kernel,world} + mergemaster phase. The reason for this is = when I tried rsyncing to copy to the FreeBSD/arm system the rsync = application would not handle file flags (noschg, etc.) properly and = rsyncing would fail, even though I'd built it with the file flags patch = enabled. Going by what you say above, that appears to work properly = now, so I may re-try that. >>=20 >> I've also not had luck cross building on a fast FreeBSD/amd64 system = and then trying to install on FreeBSD/arm by NFS mounting the src and = obj crossbuild directories and doing an install{kernel,world} + = mergemaster on the FreeBSD/arm system. When I posted about this I = believe the reason is that the build systems gets confused about the = change in build and install paths. There may also be something about = the build/install toolchain, too. I forget. I just remember it didn't = seem to work for me when I tried it and asked about it on this mailing = list. :-) >>=20 >> If someone were to do a little "fastest way to update your = FreeBSD/arm OS without having to move the SD card physically to the = build system" HOWTO, that would be great. ;-) >>=20 >> Cheers, >>=20 >> Paul. > You do need to tell rsync to handle the schg flags -- for example: >=20 > rsync -av --force-schange --fileflags -I -e 'ssh -p > ' 'karl@newfs:/pics/CrossBuild/nfsroot/' / Thanks for the tip about --force-schange. I'd used --fileflags to no = effect but didn't know about --force-schange. I'll have to try that. Cheers, Paul. From owner-freebsd-arm@freebsd.org Mon Jul 11 16:15:40 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3D7BB92C35 for ; Mon, 11 Jul 2016 16:15:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 5D6231CC9 for ; Mon, 11 Jul 2016 16:15:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 287F43A75B9 for ; Mon, 11 Jul 2016 11:15:38 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Old problem still present on 11-ALPHA1 - Pi2 Message-ID: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> Date: Mon, 11 Jul 2016 11:15:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090008050603000701070102" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:15:40 -0000 This is a cryptographically signed message in MIME format. --------------ms090008050603000701070102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have two PI2s on the same switch here doing quite-different things. One never shows network problems. The other one does this: =2E... ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:08:12:1c ugen0.4: at usbus0 umass0: on usb= us0 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 umass0:0:0: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number 00000000000000000000 da0: 40.000MB/s transfers da0: 476940MB (976773168 512 byte sectors) da0: quirks=3D0x2 random: unblocking device. smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP ue0.2: link state changed to UP ue0.3: link state changed to UP ue0: link state changed to DOWN ue0.2: link state changed to DOWN ue0.3: link state changed to DOWN ue0: link state changed to UP ue0.2: link state changed to UP ue0.3: link state changed to UP ue0: link state changed to DOWN ue0.2: link state changed to DOWN ue0.3: link state changed to DOWN ue0: link state changed to UP ue0.2: link state changed to UP ue0.3: link state changed to UP ue0: link state changed to DOWN ue0.2: link state changed to DOWN ue0.3: link state changed to DOWN ue0: link state changed to UP ue0.2: link state changed to UP ue0.3: link state changed to UP Every now and then (every hour or so) the interface flaps. If I plug a USB interface in and use two network cords I *still* get the flapping.=20 This unit has very low (but non-zero) traffic on the network, while the other actually has *more* traffic on the network yet is completely stable. Since both are plugged into the same physical switch I doubt the switch itself or its firmware is involved in this. The only difference I can see is that the one that flaps is using vlans. Specifically, that machine is the network's dhcp server, and it is on three different vlans (untagged and two tagged) so it can provide addresses (and DNS services via unbound) to those VLAN interfaces. This appears to be somehow linked to the ue interface driver, because another machine (Intel based) that is also on multiple vLANs via the em driver does *not* flap. I don't know if this is actually arm related or not; it might not be if Intel machines also use the "ue" driver, but it's very consistent on the PI2 if I want to use vlan tags whether I have one or two interfaces (the second via a USB adapter of course) in use or not. Other than the flapping the box appears to run fine; the flaps do, however, sometimes stop reporting from the snmpd daemon so I have had to stick a cron job out there to restart that on a schedule to prevent it from interrupting reporting to my traffic management tools. Whether the two are related is not known with certainty (but I suspect it is.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090008050603000701070102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExNjE1MTJaME8GCSqGSIb3DQEJBDFCBEDp kYQzhfi5vCU7sLHNJatSHY0FE/uR8eKqUmYk403zgkaRArqyMbt/Bj+HhPuGKF67KE4sF01Z Xp/xFluzjaesMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIATZiLjpRC h34dYjsofrnoSKsnmT+gx1+RTY6WluaeEjrJjI4kxpQU4pwyxj3h9Ut8Ymvu/CRC4OpwmAk0 llPs60mk9a+8qLoKdC+nEq9Ctk+JNdp5uQSuHIuIxMdqrp/WuHQy6tL9f9nCvSnYCZwgk0pJ a+rZE0cPJguvijWvuDHcXr+Vro2F/6K/pTtZ0BbTsG2fNEjZDQEkgT2MXskvQYnjtb6CDhjo QnopMEI6b/iyhBcpRF1O9Te45T3rDmJuajR8wdXx/FoWMiBEObOrmwpk+64phEdshZS3Eonj r5MDBdLSfpFzLv0p8Vx26p0VlSJ3VZL43L7S7Z0fLwwdO2IkJSuLDI3MRuG1V5hkMESKil3C UWYwh66/khQXLs9pgQoES3xOyMHQvVYRqbU6txaG3TZQZs0B6pgA8I31D8dA5Iqb14EwPsE0 gsoRE3cQupD1aTuYj1YFLSf+cfn7r745sKWwtyn0R+FUr8/uSgm1RIJ+ARrp3RT58+Xfl0JL jvNkeT4pWP9UZffHLuotkXCdmUIXNDf2mJAa/EX/RuJlrg8tGAo6Ajkgg8p/PUZ8lhWE3EU3 UTcrjtzFQfd7itao3UBpB0KkQ8webIKrxHRJ+z0eu7XBQShN2hYLEs7u29QhMV1YuZozvlhc S9PGeiClOuQ6+81PrKsTfuPcv3gAAAAAAAA= --------------ms090008050603000701070102-- From owner-freebsd-arm@freebsd.org Mon Jul 11 16:34:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9108B92418 for ; Mon, 11 Jul 2016 16:34:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EE5B1C6F for ; Mon, 11 Jul 2016 16:34:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5B48F1FE024; Mon, 11 Jul 2016 18:34:29 +0200 (CEST) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 To: Karl Denninger , "freebsd-arm@freebsd.org" References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> From: Hans Petter Selasky Message-ID: <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> Date: Mon, 11 Jul 2016 18:38:19 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:34:32 -0000 On 07/11/16 18:15, Karl Denninger wrote: > I have two PI2s on the same switch here doing quite-different things. > > One never shows network problems. The other one does this: > > .... > > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:08:12:1c > ugen0.4: at usbus0 > umass0: on usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:0:0: Attached to scbus0 > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number 00000000000000000000 > da0: 40.000MB/s transfers > da0: 476940MB (976773168 512 byte sectors) > da0: quirks=0x2 > random: unblocking device. > smsc0: chip 0xec00, rev. 0002 > ue0: link state changed to DOWN > ue0: link state changed to UP > ue0.2: link state changed to UP > ue0.3: link state changed to UP > ue0: link state changed to DOWN > ue0.2: link state changed to DOWN > ue0.3: link state changed to DOWN > ue0: link state changed to UP > ue0.2: link state changed to UP > ue0.3: link state changed to UP > ue0: link state changed to DOWN > ue0.2: link state changed to DOWN > ue0.3: link state changed to DOWN > ue0: link state changed to UP > ue0.2: link state changed to UP > ue0.3: link state changed to UP > ue0: link state changed to DOWN > ue0.2: link state changed to DOWN > ue0.3: link state changed to DOWN > ue0: link state changed to UP > ue0.2: link state changed to UP > ue0.3: link state changed to UP > > Every now and then (every hour or so) the interface flaps. If I plug a > USB interface in and use two network cords I *still* get the flapping. > This unit has very low (but non-zero) traffic on the network, while the > other actually has *more* traffic on the network yet is completely > stable. Since both are plugged into the same physical switch I doubt > the switch itself or its firmware is involved in this. > > The only difference I can see is that the one that flaps is using > vlans. Specifically, that machine is the network's dhcp server, and it > is on three different vlans (untagged and two tagged) so it can provide > addresses (and DNS services via unbound) to those VLAN interfaces. > > This appears to be somehow linked to the ue interface driver, because > another machine (Intel based) that is also on multiple vLANs via the em > driver does *not* flap. > > I don't know if this is actually arm related or not; it might not be if > Intel machines also use the "ue" driver, but it's very consistent on the > PI2 if I want to use vlan tags whether I have one or two interfaces (the > second via a USB adapter of course) in use or not. > > Other than the flapping the box appears to run fine; the flaps do, > however, sometimes stop reporting from the snmpd daemon so I have had to > stick a cron job out there to restart that on a schedule to prevent it > from interrupting reporting to my traffic management tools. Whether the > two are related is not known with certainty (but I suspect it is.) > Did you try to set any media options, like 10MBps instead of 100Mbps ? What does ifconfig say? --HPS From owner-freebsd-arm@freebsd.org Mon Jul 11 17:22:21 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B391EB92CE6 for ; Mon, 11 Jul 2016 17:22:21 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 5A39713E5 for ; Mon, 11 Jul 2016 17:22:21 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id AB7103A797A for ; Mon, 11 Jul 2016 12:22:19 -0500 (CDT) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 To: "freebsd-arm@freebsd.org" References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> From: Karl Denninger Message-ID: <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> Date: Mon, 11 Jul 2016 12:21:53 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080702060605080301070700" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:22:21 -0000 This is a cryptographically signed message in MIME format. --------------ms080702060605080301070700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/11/2016 11:38, Hans Petter Selasky wrote: > On 07/11/16 18:15, Karl Denninger wrote: >> I have two PI2s on the same switch here doing quite-different things. >> >> One never shows network problems. The other one does this: >> >> .... >> >> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ue0: on smsc0 >> ue0: Ethernet address: b8:27:eb:08:12:1c >> ugen0.4: at usbus0 >> umass0: on >> usbus0 >> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >> umass0:0:0: Attached to scbus0 >> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number 00000000000000000000 >> da0: 40.000MB/s transfers >> da0: 476940MB (976773168 512 byte sectors) >> da0: quirks=3D0x2 >> random: unblocking device. >> smsc0: chip 0xec00, rev. 0002 >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> ue0.2: link state changed to UP >> ue0.3: link state changed to UP >> ue0: link state changed to DOWN >> ue0.2: link state changed to DOWN >> ue0.3: link state changed to DOWN >> ue0: link state changed to UP >> ue0.2: link state changed to UP >> ue0.3: link state changed to UP >> ue0: link state changed to DOWN >> ue0.2: link state changed to DOWN >> ue0.3: link state changed to DOWN >> ue0: link state changed to UP >> ue0.2: link state changed to UP >> ue0.3: link state changed to UP >> ue0: link state changed to DOWN >> ue0.2: link state changed to DOWN >> ue0.3: link state changed to DOWN >> ue0: link state changed to UP >> ue0.2: link state changed to UP >> ue0.3: link state changed to UP >> >> Every now and then (every hour or so) the interface flaps. If I plug = a >> USB interface in and use two network cords I *still* get the flapping.= >> This unit has very low (but non-zero) traffic on the network, while th= e >> other actually has *more* traffic on the network yet is completely >> stable. Since both are plugged into the same physical switch I doubt >> the switch itself or its firmware is involved in this. >> >> The only difference I can see is that the one that flaps is using >> vlans. Specifically, that machine is the network's dhcp server, and i= t >> is on three different vlans (untagged and two tagged) so it can provid= e >> addresses (and DNS services via unbound) to those VLAN interfaces. >> >> This appears to be somehow linked to the ue interface driver, because >> another machine (Intel based) that is also on multiple vLANs via the e= m >> driver does *not* flap. >> >> I don't know if this is actually arm related or not; it might not be i= f >> Intel machines also use the "ue" driver, but it's very consistent on t= he >> PI2 if I want to use vlan tags whether I have one or two interfaces (t= he >> second via a USB adapter of course) in use or not. >> >> Other than the flapping the box appears to run fine; the flaps do, >> however, sometimes stop reporting from the snmpd daemon so I have had = to >> stick a cron job out there to restart that on a schedule to prevent it= >> from interrupting reporting to my traffic management tools. Whether t= he >> two are related is not known with certainty (but I suspect it is.) >> > > Did you try to set any media options, like 10MBps instead of 100Mbps ? > Yes; it makes no difference. > What does ifconfig say? > > --HPS No difference -- both are 100BaseTX connected. Machine with the problem: % ifconfig ue0 ue0: flags=3D8843 metric 0 mtu 15= 00 options=3D80009 ether b8:27:eb:08:12:1c inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 Machine without: % ifconfig ue0 ue0: flags=3D8843 metric 0 mtu 15= 00 options=3D80009 ether b8:27:eb:85:21:de inet 192.168.1.214 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 The only difference I can see between them is that the one that exhibits the flapping has vlans defined on the interface (which are working normally.) Current code on both machines: % uname -v FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016 =20 karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/s= rc/sys/RPI2 However, this has been an issue since the first 11-Current builds that had RPI2 capability in them, so it's not version-dependent either. I have been unable to find a way to log the *reason* the flap occurs (e.g. nothing in the logs indicating why it thinks link-sense disappeared, if it actually thinks it did, or if something in the code performed what amounted to an interface reset.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080702060605080301070700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExNzIxNTNaME8GCSqGSIb3DQEJBDFCBEC0 UkIghdRNY/pYt4BizQt76jUrx2DS0jG3PzCJUQP92fx+YhI+/UEgYo1UnEhJ3+ZDtmls7P8A KDV6on21vAniMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAGMhIei75 rOjmQllMf2j1yJbzXPD0mIkLbjMLR/T7c0JTknqCecuASuPScr9J06F+AEdwzAW37lXw7ajA MgfcyRDcT+qBZpKZ6mPlEsFHAH5stocdcs0uDew36ig8k8sE4ujApBMXzrcNMfNuQ0rw9q8n Hb/c/jcUoaZM2EJsL3jztqesIxKJiv0/iG7jfmoIn/fJFtnk5/Pj5QOLby2wvyoI+6NSkGJN LdgA3Fw6cAjg+bqdX/X0GIlmpNEvAx94jo9UtpzX85HEKKBuEX+REFWYpPVBgwETUWHlOh+X y/HBH5TnqWjKlNkx6OKQ9jNao2ZDLyYgLjr/qgNvKidNwo+g4oEFROUdtx3yoGApqOrzw9UC I3woD1ftJjV/bFZxD7XcKQjO3/pxLsMoPnG5p6v3aHhKpVPOuDPqAW4Fd232ABF1lHVwx5b8 Zt/JDo5xb7VpuYAq3efsgpzAMy9XaCBk7kf/7vkQbpq4pKWNUFowUCH6KeW0Iy3WIkxOo1vh LmICc+oeOwJfCS8OYD2ABDXQv8XsGykJU3l6HG4TwHDOAPW5R8ysXStQIlx0hodl0/iIuDpy MaiXzc83XYtk7ziS1weLbCsR9068GE1AcZt3v6nhOpqVe3LEyanZCiIdQ3H2zX/FLH8Szdcj FSl5bUImoUhWrlCEnohVo86teWQAAAAAAAA= --------------ms080702060605080301070700-- From owner-freebsd-arm@freebsd.org Mon Jul 11 21:02:25 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE413B92F51 for ; Mon, 11 Jul 2016 21:02:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EDC31B8D for ; Mon, 11 Jul 2016 21:02:24 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u6BKx21G081851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 22:59:08 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u6BKwtk1093177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jul 2016 22:58:55 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u6BKwtFl034571; Mon, 11 Jul 2016 22:58:55 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u6BKwtxF034570; Mon, 11 Jul 2016 22:58:55 +0200 (CEST) (envelope-from ticso) Date: Mon, 11 Jul 2016 22:58:55 +0200 From: Bernd Walter To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 Message-ID: <20160711205855.GC34367@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:02:25 -0000 On Mon, Jul 11, 2016 at 12:21:53PM -0500, Karl Denninger wrote: > On 7/11/2016 11:38, Hans Petter Selasky wrote: > > On 07/11/16 18:15, Karl Denninger wrote: > > Did you try to set any media options, like 10MBps instead of 100Mbps ? > > > Yes; it makes no difference. > > > What does ifconfig say? > > > > --HPS > No difference -- both are 100BaseTX connected. > > Machine with the problem: > % ifconfig ue0 > ue0: flags=8843 metric 0 mtu 1500 > options=80009 > ether b8:27:eb:08:12:1c > inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > > > Machine without: > % ifconfig ue0 > ue0: flags=8843 metric 0 mtu 1500 > options=80009 > ether b8:27:eb:85:21:de > inet 192.168.1.214 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > > The only difference I can see between them is that the one that exhibits > the flapping has vlans defined on the interface (which are working > normally.) > > Current code on both machines: > % uname -v > FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016 > karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/src/sys/RPI2 > > However, this has been an issue since the first 11-Current builds that > had RPI2 capability in them, so it's not version-dependent either. Sure it is not the board, powersupply, cable or switchport? Check if the red power LED on the Raspberry is on - it goes off under a certain supply voltage, although the board contiues to work. AFAIK all Raspberries have the same ethernet chip. Well - some earlier B (not B+) had used the 9512 instead of the 9514. Doesn't sound very logical if the same driver behaves different. A link down/up isn't something I would expect from the host controller causing this either. I also never had this problem on a Pi2. > I have been unable to find a way to log the *reason* the flap occurs > (e.g. nothing in the logs indicating why it thinks link-sense > disappeared, if it actually thinks it did, or if something in the code > performed what amounted to an interface reset.) Usually it is the PHY (which is integrated into the 9514), that detects and negotiates the link. The PHY runs on it's own internal state machine. The OS just gets informed, so that it can trigger some processing, such as updating the MAC for the negotiated link speed/duplex, logging the event, ... -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Jul 11 22:26:06 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41B49B92969 for ; Mon, 11 Jul 2016 22:26:06 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh602-vm11.bullet.mail.ssk.yahoo.co.jp (nh602-vm11.bullet.mail.ssk.yahoo.co.jp [182.22.90.36]) by mx1.freebsd.org (Postfix) with SMTP id B1B2D1757 for ; Mon, 11 Jul 2016 22:26:05 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.103] by nh602.bullet.mail.ssk.yahoo.co.jp with NNFMP; 11 Jul 2016 22:23:53 -0000 Received: from [182.22.91.131] by t601.bullet.mail.ssk.yahoo.co.jp with NNFMP; 11 Jul 2016 22:23:53 -0000 Received: from [127.0.0.1] by omp604.mail.ssk.yahoo.co.jp with NNFMP; 11 Jul 2016 22:23:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 795589.76309.bm@omp604.mail.ssk.yahoo.co.jp Received: (qmail 85704 invoked by uid 60001); 11 Jul 2016 22:23:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1468275833; bh=bhXCd7+ngKRHnUOQSUD+fzx5zF7rLrCnVejJTkYrii8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=QpAW/HzMqP6u+/PBvhdEzeuCzB9NWqkpFOa6LR2rhgX2jG3Kyrz/r5/saa8dm7tEvn/Aqp2p3ZG976qK8TOwT5t/y6HchWtH1oxChhWWOvdnVK8nrhNXOoXnoihYuM6nLNCk3CKZ7RJFLLvZWjo303fOQgNrU4GUNEOBbylufGE= 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; b=MM6zuCwT6vcQpm012HjQR8aNg3ENct5POfeo9CkE/yDHYx1yB4+f2zAjEzjUOVDFB5qHMGMKrPbobXhG1QccuvF/0mGtytlBrXgx051lgDJFHGFXT1KNKr5foj7NGtNmy0NrHSmctDlTfW13XPIZzeW0K2B7YOubj8QSVBRGNco=; Message-ID: <681626.83208.qm@web101715.mail.ssk.yahoo.co.jp> X-YMail-OSG: rwllMS8VM1lqYCa_T3FL5nDKeTIOjLUENH80FQSDIG5DAqm6iynEQfMbsN107jNA_e.j_.WxzsJhwRefkORj7jE68O2FDST2RD9YtjcBG9CDvvo.gVjuFopV3WKqCR5j.LH5dZ4HGbp9ph9akjbQ3XT9y4p4wgbUzoOwiQmZZAFFpvzQqQIJsPxNPm2FHBXzc5kQlRF5GqG5nfw.ywb_n9Awd4VpdzSsxCO9mdB2nYqxda1knpPAwiWiqai2L0W.TWb0uQtyetSYl_91TggRhUMX93aLTUNlMU3eOjjKVQuT0DTcr.kuGqpa6j6a85u2PJvzlGEAdLvzzCt3gJlFIwQFiON1_n1gtfI.e_XquErUh6bn4b7.8NDQglikMpRMcGEQNts5m5yt87Ews4eum0LCF5Ch3sP5e0vvlMaHDDfV_0m99PBScXtWDSqtcvcHfe_etksnz04P1yFbhV5qv3ZBzUke0VRMeT_UAezf3dXXlgE.35eWQg7jp7XwlhM217cfq0zkbbtJbZqxR0NGr8.aDxsdDRAJ_2h4BahCHU2Tha1SP6iY Received: from [110.134.196.53] by web101715.mail.ssk.yahoo.co.jp via HTTP; Tue, 12 Jul 2016 07:23:53 JST X-Mailer: YahooMailWebService/0.8.111_69 X-YMail-JAS: jXLGWA8VM1lkMuJgeEMl1WMSqMua8OuHm794odE.021x6BJ_4CtlSaqncCXhb7qfNOkXu2xlR7swepIeRPjHThndj8p8U41k_Bye2O8NNsxtTwAKrDfNlDEX6mdFefAsB98w Date: Tue, 12 Jul 2016 07:23:53 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: RT1310 support To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 22:26:06 -0000 Hi=0A=0AThis is Ralink old arm soc RT1310A support code.=0A=0Ahttps://githu= b.com/yamori813/freebsd/tree/zrouter/sys/arm/ralink=0A=0A=0Admesg is here.= =A0=0A=0Ahttps://gist.github.com/yamori813/88224f1c96c9c592fb611b12a15e4ab5= =0A=0A=0AI like old soc. :)=0A=0AHiroki Mori From owner-freebsd-arm@freebsd.org Mon Jul 11 22:54:47 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1F20B923AD for ; Mon, 11 Jul 2016 22:54:47 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B5B0E1DB8; Mon, 11 Jul 2016 22:54:47 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id C349F16B; Mon, 11 Jul 2016 22:54:47 +0000 (UTC) Date: Mon, 11 Jul 2016 22:54:45 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: nwhitehorn@FreeBSD.org, jmcneill@FreeBSD.org, ache@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <213960252.34.1468277687810.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3570 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 22:54:47 -0000 FreeBSD_HEAD_arm64 - Build #3570 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3570/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3570/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3570/console Change summaries: 302595 by nwhitehorn: Remove assumptions in MI code that the BSP is CPU 0. MFC after: 2 weeks 302594 by ache: 1) Following r302512 (remove collation support for [a-z]-ranges in libc) remove collation support for a-z ranges here too. It was implemented for single byte locales only in any case. 2) Reduce [Cc]flag loop to WCHAR_MAX, WINT_MAX here includes WEOF which is not a character. 3) Optimize [Cc]flag case: don't repeatedly add the last character of string2 to squeeze cset when string2 reach its EOS state. 4) Reflect in the manpage that [=equiv=] is implemented for single byte locales only. 302593 by jmcneill: Add support for Allwinner A64. Reviewed by: andrew, manu 302592 by jmcneill: Return early from bus_dmamap_load callback if the error indicator is set. Reviewed by: andrew, manu 302591 by jmcneill: Add support for arm64. The allwinner_soc_family() function is not available on arm64 and all SoCs using the old FIFO register location are 32-bit only, so unconditionally use the new location for arm64. Reviewed by: andrew, manu 302590 by jmcneill: Add support for Allwinner A64 CPUx-PORT and CPUs-PORT Port Controllers. Reviewed by: andrew, manu 302589 by jmcneill: Add Allwinner A64 padconf settings. Reviewed by: andrew, manu 302588 by jmcneill: Add SOC_ALLWINNER_A64 option for Allwinner A64 (sun50i) SoCs. 302587 by jmcneill: Include sys/rman.h to fix build on arm64. 302586 by jmcneill: Attach RSB early. Children of RSB may provide resources necessary for other devices such as interrupts, GPIOs, and regulators. 302585 by jmcneill: Build fix for arm64. The phy interface uses intptr_t for the "phy" parameter, not int. 302584 by jmcneill: Remove unused bus_space prototypes. The end of the build log: [...truncated 119195 lines...] cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/lib/libucl/../../contrib/libucl/include -I/usr/src/lib/libucl/../../contrib/libucl/src -I/usr/src/lib/libucl/../../contrib/libucl/uthash -I/usr/src/lib/libucl/../../contrib/libucl/klib -MD -MF.depend.ucl_hash.po -MTucl_hash.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/libucl/../../contrib/libucl/src/ucl_hash.c -o ucl_hash.po --- all_subdir_usr.bin --- --- screen.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DHAVE_GETOPT -DHAVE_STRERROR -DORDER -I/usr/src/usr.bin/top -I/usr/src/usr.bin/top/../../contrib/top -I. -g -MD -MF.depend.screen.o -MTscreen.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/usr.bin/top/../../contrib/top/screen.c -o screen.o --- all_subdir_usr.sbin --- --- psscope.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.psscope.o -MTpsscope.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/parser/psscope.c -o psscope.o --- all_subdir_usr.bin --- /usr/src/usr.bin/top/../../contrib/top/screen.c:136:19: warning: implicit declaration of function 'tgetent' is invalid in C99 [-Wimplicit-function-declaration] if ((status = tgetent(termcap_buf, term_name)) != 1) ^ /usr/src/usr.bin/top/../../contrib/top/screen.c:154:9: warning: implicit declaration of function 'tgetflag' is invalid in C99 [-Wimplicit-function-declaration] if (tgetflag("hc")) ^ /usr/src/usr.bin/top/../../contrib/top/screen.c:161:26: warning: implicit declaration of function 'tgetnum' is invalid in C99 [-Wimplicit-function-declaration] if ((screen_length = tgetnum("li")) <= 0) ^ /usr/src/usr.bin/top/../../contrib/top/screen.c:318:2: warning: implicit declaration of function 'tputs' is invalid in C99 [-Wimplicit-function-declaration] putcap(terminal_init); ^ /usr/src/usr.bin/top/../../contrib/top/screen.h:9:44: note: expanded from macro 'putcap' #define putcap(str) (void)((str) != NULL ? TCputs(str) : 0) ^ /usr/src/usr.bin/top/../../contrib/top/screen.h:8:21: note: expanded from macro 'TCputs' #define TCputs(str) tputs(str, 1, putstdout) ^ 4 warnings generated. --- top.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DHAVE_GETOPT -DHAVE_STRERROR -DORDER -I/usr/src/usr.bin/top -I/usr/src/usr.bin/top/../../contrib/top -I. -g -MD -MF.depend.top.o -MTtop.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/usr.bin/top/../../contrib/top/top.c -o top.o --- all_subdir_usr.sbin --- --- pstree.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.pstree.o -MTpstree.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/parser/pstree.c -o pstree.o --- all_subdir_secure --- --- prime.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMONOLITH -g -MD -MF.depend.prime.o -MTprime.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/prime.c -o prime.o --- all_subdir_usr.sbin --- --- psutils.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.psutils.o -MTpsutils.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/parser/psutils.c -o psutils.o --- all_subdir_lib --- --- ucl_msgpack.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/lib/libucl/../../contrib/libucl/include -I/usr/src/lib/libucl/../../contrib/libucl/src -I/usr/src/lib/libucl/../../contrib/libucl/uthash -I/usr/src/lib/libucl/../../contrib/libucl/klib -MD -MF.depend.ucl_msgpack.po -MTucl_msgpack.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/libucl/../../contrib/libucl/src/ucl_msgpack.c -o ucl_msgpack.po --- all_subdir_usr.sbin --- --- pswalk.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.pswalk.o -MTpswalk.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/parser/pswalk.c -o pswalk.o --- all_subdir_secure --- --- rand.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMONOLITH -g -MD -MF.depend.rand.o -MTrand.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/rand.c -o rand.o --- all_subdir_usr.sbin --- --- nsaccess.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.nsaccess.o -MTnsaccess.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nsaccess.c -o nsaccess.o --- all_subdir_usr.bin --- --- username.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DHAVE_GETOPT -DHAVE_STRERROR -DORDER -I/usr/src/usr.bin/top -I/usr/src/usr.bin/top/../../contrib/top -I. -g -MD -MF.depend.username.o -MTusername.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/usr.bin/top/../../contrib/top/username.c -o username.o --- utils.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DHAVE_GETOPT -DHAVE_STRERROR -DORDER -I/usr/src/usr.bin/top -I/usr/src/usr.bin/top/../../contrib/top -I. -g -MD -MF.depend.utils.o -MTutils.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/usr.bin/top/../../contrib/top/utils.c -o utils.o --- all_subdir_secure --- --- req.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMONOLITH -g -MD -MF.depend.req.o -MTreq.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/req.c -o req.o --- all_subdir_lib --- --- ucl_parser.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/lib/libucl/../../contrib/libucl/include -I/usr/src/lib/libucl/../../contrib/libucl/src -I/usr/src/lib/libucl/../../contrib/libucl/uthash -I/usr/src/lib/libucl/../../contrib/libucl/klib -MD -MF.depend.ucl_parser.po -MTucl_parser.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/libucl/../../contrib/libucl/src/ucl_parser.c -o ucl_parser.po --- all_subdir_usr.sbin --- --- nsalloc.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.nsalloc.o -MTnsalloc.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nsalloc.c -o nsalloc.o --- all_subdir_usr.bin --- --- version.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DHAVE_GETOPT -DHAVE_STRERROR -DORDER -I/usr/src/usr.bin/top -I/usr/src/usr.bin/top/../../contrib/top -I. -g -MD -MF.depend.version.o -MTversion.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/usr.bin/top/../../contrib/top/version.c -o version.o --- top.full --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DHAVE_GETOPT -DHAVE_STRERROR -DORDER -I/usr/src/usr.bin/top -I/usr/src/usr.bin/top/../../contrib/top -I. -g -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -o top.full commands.o display.o machine.o screen.o top.o username.o utils.o version.o -lncursesw -lm -lkvm -ljail --- top.x --- Making top.x from /usr/src/usr.bin/top/../../contrib/top/top.xs --- top.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug top.full top.debug --- top.1 --- cat top.x /usr/src/usr.bin/top/top.local.1 > top.1 --- top --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=top.debug top.full top --- top.1.gz --- gzip -cn top.1 > top.1.gz --- all_subdir_usr.bin/touch --- ===> usr.bin/touch (all) --- all_subdir_usr.sbin --- --- nsdump.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.nsdump.o -MTnsdump.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nsdump.c -o nsdump.o --- all_subdir_usr.bin --- --- .depend --- echo touch.full: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a >> .depend --- touch.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.touch.o -MTtouch.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/touch/touch.c -o touch.o --- touch.full --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o touch.full touch.o --- all_subdir_usr.sbin --- --- nsnames.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.nsnames.o -MTnsnames.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nsnames.c -o nsnames.o --- all_subdir_usr.bin --- --- touch.1.gz --- gzip -cn /usr/src/usr.bin/touch/touch.1 > touch.1.gz --- touch.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug touch.full touch.debug --- touch --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=touch.debug touch.full touch --- all_subdir_usr.bin/tput --- ===> usr.bin/tput (all) --- .depend --- echo tput.full: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libncursesw.a >> .depend --- tput.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.tput.o -MTtput.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/tput/tput.c -o tput.o --- all_subdir_usr.sbin --- --- nsobject.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.nsobject.o -MTnsobject.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nsobject.c -o nsobject.o --- all_subdir_usr.bin --- --- tput.full --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o tput.full tput.o -lncursesw --- tput.1.gz --- gzip -cn /usr/src/usr.bin/tput/tput.1 > tput.1.gz --- tput.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug tput.full tput.debug --- tput --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=tput.debug tput.full tput --- all_subdir_usr.bin/tr --- ===> usr.bin/tr (all) --- .depend --- echo tr.full: /usr/obj/arm64.aarch64/usr/src/tmp/usr/lib/libc.a >> .depend --- cmap.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.cmap.o -MTcmap.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/tr/cmap.c -o cmap.o --- all_subdir_usr.sbin --- --- nsparse.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.nsparse.o -MTnsparse.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nsparse.c -o nsparse.o --- all_subdir_usr.bin --- --- cset.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.cset.o -MTcset.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/tr/cset.c -o cset.o --- all_subdir_usr.sbin --- --- nssearch.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.nssearch.o -MTnssearch.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nssearch.c -o nssearch.o --- all_subdir_usr.bin --- --- str.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.str.o -MTstr.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/tr/str.c -o str.o --- all_subdir_secure --- --- rsa.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMONOLITH -g -MD -MF.depend.rsa.o -MTrsa.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/rsa.c -o rsa.o --- all_subdir_usr.sbin --- --- nsutils.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -g -MD -MF.depend.nsutils.o -MTnsutils.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/namespace/nsutils.c -o nsutils.o --- all_subdir_usr.bin --- --- tr.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -g -MD -MF.depend.tr.o -MTtr.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/tr/tr.c -o tr.o /usr/src/usr.bin/tr/tr.c:269:21: error: comparison of integers of different signs: 'wint_t' (aka 'int') and 'unsigned int' [-Werror,-Wsign-compare] for (cnt = 0; cnt <= WCHAR_MAX; cnt++) { ~~~ ^ ~~~~~~~~~ 1 error generated. *** [tr.o] Error code 1 bmake[4]: stopped in /usr/src/usr.bin/tr 1 error bmake[4]: stopped in /usr/src/usr.bin/tr *** [all_subdir_usr.bin/tr] Error code 2 bmake[3]: stopped in /usr/src/usr.bin 1 error bmake[3]: stopped in /usr/src/usr.bin *** [all_subdir_usr.bin] Error code 2 bmake[2]: stopped in /usr/src --- all_subdir_secure --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/secure/usr.bin/openssl *** [all_subdir_secure/usr.bin/openssl] Error code 2 bmake[4]: stopped in /usr/src/secure/usr.bin 1 error bmake[4]: stopped in /usr/src/secure/usr.bin *** [all_subdir_secure/usr.bin] Error code 2 bmake[3]: stopped in /usr/src/secure 1 error bmake[3]: stopped in /usr/src/secure *** [all_subdir_secure] Error code 2 bmake[2]: stopped in /usr/src --- all_subdir_usr.sbin --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/usr.sbin/acpi/iasl *** [all] Error code 2 bmake[4]: stopped in /usr/src/usr.sbin/acpi 1 error bmake[4]: stopped in /usr/src/usr.sbin/acpi *** [all_subdir_usr.sbin/acpi] Error code 2 bmake[3]: stopped in /usr/src/usr.sbin 1 error bmake[3]: stopped in /usr/src/usr.sbin *** [all_subdir_usr.sbin] Error code 2 bmake[2]: stopped in /usr/src --- all_subdir_lib --- A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/lib/libucl *** [all_subdir_lib/libucl] Error code 2 bmake[3]: stopped in /usr/src/lib 1 error bmake[3]: stopped in /usr/src/lib *** [all_subdir_lib] Error code 2 bmake[2]: stopped in /usr/src 4 errors bmake[2]: stopped in /usr/src *** [everything] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson3839613308534732910.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Mon Jul 11 23:29:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1471AB92D89 for ; Mon, 11 Jul 2016 23:29:35 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mailbox.org", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C97311393 for ; Mon, 11 Jul 2016 23:29:34 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 622B843AD8 for ; Tue, 12 Jul 2016 01:22:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:date:date:message-id:from:from:references:subject :subject:received; s=mail20150812; t=1468279370; bh=7CZrW+ImTbgH vaCsa7XEMiky0Vnn8iEUeG6jWplcmck=; b=VrLu8hFM6OgAlPAczo2P8r6dJ7Z4 Lw2gaVNluJ2r7+oG1T78fGgsjgvRUz9+2q+NDOa1aDDYFLsZXeC2ORMOK8v0/aw6 +VwEdhhUGmplmC7/uzAGi7fHFllgVsP+3jFwUQ2m6gwfl9EYa9xjXLl/3JuSLdUd jcWHQWMnchbwrXr3nI/8YtL5HhZoKdu9AUk0kunQe4Ysu3WG7w+Z7SNnV/1zeUao O7OlbT0yxCyN9tn8mLBWx/OrqxgCf+UL/6eQWp++fyz0ThBlFW8R9oF8Jq7IwQfy iqwlq5AHHYTA+XhwE6n1UqsfhMXhgujcA9+gbBTIoHOfe+60gk/ikK2dtQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id 9SxtUJqraiyM for ; Tue, 12 Jul 2016 01:22:50 +0200 (CEST) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 To: freebsd-arm@freebsd.org References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> From: "Herbert J. Skuhra" Message-ID: Date: Tue, 12 Jul 2016 01:22:49 +0200 MIME-Version: 1.0 In-Reply-To: <20160711205855.GC34367@cicely7.cicely.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 23:29:35 -0000 On 11/07/16 22:58, Bernd Walter wrote: > > Sure it is not the board, powersupply, cable or switchport? > Check if the red power LED on the Raspberry is on - it goes off under > a certain supply voltage, although the board contiues to work. Hmm, the LEDs (red/green) on the RPI2 should work on FreeBSD? I have two RPIs 2 (and one RPI3) and three different power supplies and the red LED is only on for a few seconds after connecting the power cable. The LEDs are working permanently when I run Arch Linux ARM. -- Herbert From owner-freebsd-arm@freebsd.org Tue Jul 12 00:07:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71693B92452 for ; Tue, 12 Jul 2016 00:07:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 287A81FCB for ; Tue, 12 Jul 2016 00:07:08 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 543EB22016F for ; Mon, 11 Jul 2016 19:07:06 -0500 (CDT) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 To: freebsd-arm@freebsd.org References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> From: Karl Denninger Message-ID: Date: Mon, 11 Jul 2016 19:06:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090809010008040408000304" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 00:07:09 -0000 This is a cryptographically signed message in MIME format. --------------ms090809010008040408000304 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/11/2016 18:22, Herbert J. Skuhra wrote: > On 11/07/16 22:58, Bernd Walter wrote: >> Sure it is not the board, powersupply, cable or switchport? >> Check if the red power LED on the Raspberry is on - it goes off under >> a certain supply voltage, although the board contiues to work. > Hmm, the LEDs (red/green) on the RPI2 should work on FreeBSD? > > I have two RPIs 2 (and one RPI3) and three different power supplies and= > the red LED is only on for a few seconds after connecting the power > cable. The LEDs are working permanently when I run Arch Linux ARM. That's the default, yes. The red LED goes out when the kernel loads. However, I have a little daemon process that blinks the green one, so I know it's running, and it works fine... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090809010008040408000304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTIwMDA2NDBaME8GCSqGSIb3DQEJBDFCBEAb vwjLPrGuwR/b3c28hDQbEhRKR2/XwEXqJLD2EEwyJo3lxPt+boJr4USIPNZSmSL+8cuDowtl zbLB822reBT+MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAFjubmVj4 JgSoqkTj2BfO5OtlZWIk7S21G9i+y54onTT0nHmtc/81WacmlX18STFKQnM5bDYvn6nay0/m 61pDJZxGsqTl9pQmCOtCaTgV4PWkVpEVTNdwqs1ALMoVGXPJwQJ7S80qQ4EyJnZLuJ/6ASOr XGGw7FU+cGMH5gytZVKdRQiGmESqPq9GTKxepOR5X/kP3+iydNgVI15VwfUqvdeklsyFdHBD 0qprcNJ79+C8pw5x2u8VrbT3BLt1MovgOAqfGU9oRZ5LpeiVsBuwL8emgPbDkDPZoRTPbGMA aSWvp9qwv399rsSyP40Q/btyA4Hv7QkibH7qPm43aJ3DFxCHt0QNmPPE1g0Oxsce+fJGJKXU UUkpGKuvzHyK7Xz6Q2g3/DWBkxme/2ILB4Fh9a1qH/XEHgY66riyTaRjjoIa32il8G+456sN FyhHM1y1IbkQ+tExOa8qfRuOmIbGreXseUuAjZrsy0WmbUQeFyThpBIfrULV1BYMPZW3Je4d 281YEhCwxsAHaYS2h8d2nerPpgKF6v4BhOMJKJUf7q/Peb6P2GOe+sPYAug3QTnaQjonoqD8 F7aWZR5/pjIxX4MVGg2v67ULUvneLhhmSsxMCs40gYZWC5e/DPjS1uOV+/jeT0POdi4rKVQJ Z0wjnCXGEW/LmaAcLZ9/xX/kBhUAAAAAAAA= --------------ms090809010008040408000304-- From owner-freebsd-arm@freebsd.org Tue Jul 12 01:05:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85375B832E8 for ; Tue, 12 Jul 2016 01:05:13 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 757151B17; Tue, 12 Jul 2016 01:05:13 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B79F716E; Tue, 12 Jul 2016 01:05:13 +0000 (UTC) Date: Tue, 12 Jul 2016 01:05:12 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: gjb@FreeBSD.org, ache@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <748597816.36.1468285513760.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <213960252.34.1468277687810.JavaMail.jenkins@jenkins-9.freebsd.org> References: <213960252.34.1468277687810.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3571 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 01:05:13 -0000 FreeBSD_HEAD_arm64 - Build #3571 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3571/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3571/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3571/console Change summaries: 302599 by ache: Cast WCHAR_MAX to wint_t, it can be unsigned on some systems. 302596 by gjb: Fix TARGET_TRIPLE for 12.0-CURRENT. Submitted by: rene Sponsored by: The FreeBSD Foundation From owner-freebsd-arm@freebsd.org Tue Jul 12 01:28:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC3FDB8391C for ; Tue, 12 Jul 2016 01:28:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 6FE78196E for ; Tue, 12 Jul 2016 01:28:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id EB02822060B for ; Mon, 11 Jul 2016 20:28:46 -0500 (CDT) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> Cc: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <5f38e923-c1a1-8bb7-83cc-0de6404b6e47@denninger.net> Date: Mon, 11 Jul 2016 20:28:19 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160711205855.GC34367@cicely7.cicely.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030206050001040703020301" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 01:28:49 -0000 This is a cryptographically signed message in MIME format. --------------ms030206050001040703020301 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/11/2016 15:58, Bernd Walter wrote: > On Mon, Jul 11, 2016 at 12:21:53PM -0500, Karl Denninger wrote: >> On 7/11/2016 11:38, Hans Petter Selasky wrote: >>> On 07/11/16 18:15, Karl Denninger wrote: >>> Did you try to set any media options, like 10MBps instead of 100Mbps = ? >>> >> Yes; it makes no difference. >> >>> What does ifconfig say? >>> >>> --HPS >> No difference -- both are 100BaseTX connected. >> >> Machine with the problem: >> % ifconfig ue0 >> ue0: flags=3D8843 metric 0 mtu= 1500 >> options=3D80009 >> ether b8:27:eb:08:12:1c >> inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=3D29 >> >> >> Machine without: >> % ifconfig ue0 >> ue0: flags=3D8843 metric 0 mtu= 1500 >> options=3D80009 >> ether b8:27:eb:85:21:de >> inet 192.168.1.214 netmask 0xffffff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=3D29 >> >> The only difference I can see between them is that the one that exhibi= ts >> the flapping has vlans defined on the interface (which are working >> normally.) >> >> Current code on both machines: >> % uname -v >> FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016 =20 >> karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuil= d/src/sys/RPI2 >> >> However, this has been an issue since the first 11-Current builds that= >> had RPI2 capability in them, so it's not version-dependent either. > Sure it is not the board, powersupply, cable or switchport? Yes, considering that I have (multiple times) swapped literally everything (I have a bunch of PI2s here.) Just for grins and giggles I did it again; swapped in a known working (no problems of this sort) board, power supply that was used with it and network cable, and moved it to a different switch port. The problem is still there. It *only* happens if I have the VLANs enabled. If I am running a single network on an interface it's fine. > Check if the red power LED on the Raspberry is on - it goes off under > a certain supply voltage, although the board contiues to work. Uh, the red LED only comes on during the boot sequence until the kernel init's the GPIO on FreeBSD. You're thinking of Linux. I have a little program that runs and slowly blinks the green LED though once started; it's purpose is to provide a visible "system is running" indication. > > AFAIK all Raspberries have the same ethernet chip. > Well - some earlier B (not B+) had used the 9512 instead of the 9514. > Doesn't sound very logical if the same driver behaves different. > A link down/up isn't something I would expect from the host controller > causing this either. > I also never had this problem on a Pi2. How many people are running three networks (base plus two VLANs) on them?= >> I have been unable to find a way to log the *reason* the flap occurs >> (e.g. nothing in the logs indicating why it thinks link-sense >> disappeared, if it actually thinks it did, or if something in the code= >> performed what amounted to an interface reset.) > Usually it is the PHY (which is integrated into the 9514), that detects= > and negotiates the link. > The PHY runs on it's own internal state machine. > The OS just gets informed, so that it can trigger some processing, > such as updating the MAC for the negotiated link speed/duplex, logging > the event, ... I know. This has been an issue since the first RPI2 builds with this particular configuration -- and still is. If I could figure out *why* it thinks the PHY is going down I could track it down, but there's nothing I can find that tells me that. Oh, and the switch doesn't think it flapped either (!!); there is nothing in the switch log about the link being lost and restored. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030206050001040703020301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTIwMTI4MTlaME8GCSqGSIb3DQEJBDFCBECm Qy3Mf0u0VsS+DQ5NNqJp6ao/bpByp7Hq8sO11S3z5peUvHTw6NiYK9vdi3X0TTGJF642JgbF dxjlA8JOh9BQMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAgByQ/9vz 3VIx5Qw8O97sAj84gHj3Fu9c1bc6fSY0jDteHne55xVjyiJER4oiv45Uf06HllAseNfIE10A kEthVuRQQ8yyWxKEXTHmfHRoEGFWa1S0ypESVLApRSQ0OZ0xiC6Lurysngn6EVdN1yfDMU2/ 3GxXuXTx/VlOLGiRSWhuPpkQtSFAD3KZPjtNQItlvAeQ8e6Hqvl9Jf2239+sBPr4w2+TtpsL 2GIDdASJFkJg3ViIFlO/q25XkjcWbh1mGc/Ky4ZQd3X3/rHcZFy4Z+CO+Osiey6sVwPTTTSM /3SpZarQaH+cNUbtrua8nH3XoNNDiobUEDL3MQFlOMF+IVW7olETKQSPxCeOF9KNGRo4wVfv b/c5i0kDipZRivKwi60luTCAMC3dK7fWZKlFGWq+anvTByWq4LS03gaGVBJN+f7TFvGWCwmz PZ9pt4k9ASZ9jzVMAyJ6HZDvEhZHbRRjPPl2/Ft0f6AbhCaIHzPxCJ7DwvU5eSPrYvZF40GU QYf4w+IGGd+KZxqv+lW7kw8yVOoLg51BLRp/2bRcZ7I/vTXrKtTbJX+K7wQiJVKakuqv8dW8 R7Ye/GULL+FO86sRjOFpwJsdABo7kruaSWoTEbjBWXv88Qno420lVvr9+w3XE1w+olXVB0zB e9uP6oJiWy40IOx9M210aqAZlC8AAAAAAAA= --------------ms030206050001040703020301-- From owner-freebsd-arm@freebsd.org Tue Jul 12 08:09:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 166A9B93C3A for ; Tue, 12 Jul 2016 08:09:19 +0000 (UTC) (envelope-from bounce_FokWuZ8rV5rX7obd_4UqrJjwkknMQ2VWX_2bb7fca0c43238e7_3@yomoko-mail.com) Received: from s5.mtb-4.com (s5.mtb-3.com [69.63.158.45]) (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 561BB1CEF for ; Tue, 12 Jul 2016 08:09:13 +0000 (UTC) (envelope-from bounce_FokWuZ8rV5rX7obd_4UqrJjwkknMQ2VWX_2bb7fca0c43238e7_3@yomoko-mail.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mykey2; d=mtb-4.com; h=Reply-To:List-Unsubscribe:From:To:Subject:MIME-Version:Date:Message-Id:Content-Type; bh=irsld0HoHEb8WM3PkrjS+UZdz90=; b=XUgxkJ3hdGpsilqrjFXTRB3xi7BTZoetLOxkjgufvkF8BWXwDRyDAXQoJn4UMidw6Gr7BP2E2t7H mq+ggudcnI8y1iqCr3tA7kvnvfYYTpdhyei/wUwg540KvAUb+00dTPqQWL/FzFlrkEkkGgkQpNEX uFvL6LjTLy7n86sbFXiZAlHI4DJHd9Dkj/T7IFjOM0s0BOBSHSJW6qziMjh57rrym8EhWhugd+LF Cr5RSlD1V6mN6FJV4Qhnx3D0gr3tT2gsKytfIA0kAG0Uv6FZs2cRqQSNr8H2yOXLsjUmV82+nFEj 8EFaXlHhZK9PPBTVhqF201ec2wGIbYljOzotsw== Received: from localhost (10.10.204.18) by s5.mtb-4.com id hgiiqm27la8v for ; Tue, 12 Jul 2016 09:12:36 +0200 (envelope-from ) Reply-To: mala.augustine@educor.co.za X-Priority: 3 X-Report-Abuse: X-Data: 4UqrJjwkknMQ2VWX.2bb7fca0c43238e7 X-Data-EUID: 60fc35abe270e6bd870760efc7821468 X-Data-Rating: -2 From: Damelin To: freebsd-arm@freebsd.org Subject: Join the School of Business Professionals MIME-Version: 1.0 Date: Tue, 12 Jul 2016 09:12:02 +0200 Message-Id: <201607129091236.29478.1152@dcc.edu.za> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 08:09:19 -0000 School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) From owner-freebsd-arm@freebsd.org Tue Jul 12 08:10:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C4B4B93E97 for ; Tue, 12 Jul 2016 08:10:32 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 4397B1EB1 for ; Tue, 12 Jul 2016 08:10:32 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x229.google.com with SMTP id o63so11306511vkg.1 for ; Tue, 12 Jul 2016 01:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pcV1EKHHRgV3c/x1A9pA5rkgWvWuIbSCid0zOCPDEPY=; b=SPwKZa00yOham/C+yTFb6JW2JRpYWcB+ne6CokwOvLOOpZsV+5DP0Do0tKLm9Onk/K mwAmOWwlSP98bSZvB5rWkWkzfmS82S8/be8vuszRNHZD84rVd6bY78Xw09qeoO5duN01 XxF70uNoZf7eALnsfKT7qUubs7ZMP0tm4l4XaVIeHlpnFJDux0sNCd3+Sa+80eBIAP7C QTh0h6nY9+p2zG0zgJJXDp09nKyciqTpDlsbS1qH3csmKQ84H1Z3tJ0dnw0z/qQFWXPz 5vJNJMTJ6EJaEFq3TomjWWXvVu6p7Hwm6JImhXbpN9EfUmXSclsU91PllrrKFf3xYOXR 5x3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pcV1EKHHRgV3c/x1A9pA5rkgWvWuIbSCid0zOCPDEPY=; b=BBAslmgN2ZXRjOzw/P7H+hkm4rjJfUdWc1E1xRU3BJj0/0D+N6J1ih7AGG4j/8XUod bPhi4jVWadJN2gQOYJkmnmyPnKwyMZM4oGprWouvYJ4lVrhCByxS0DxTZ0SWGB3YQWxj PuPmlLerqMN5XtguFux7yrO0ojNgb7o3b17rj2SX8Cf+VaLFedrwxJTV+0RNqY/dpSc0 o0Dhi/9pWNUvtRQWyKEOrnb95jnPDax5Y6pF3SfRP8NLTkMQs3IkLC8yN5BdOzJjYQPq ByDOZvgjY9F2GbJYizh/rM9JDUbNMv4ZUC8W4ZCqGa7eN7ZilkF1phWEmpgE+9CINU4P LOxg== X-Gm-Message-State: ALyK8tLFvpJQFnuQyrW7fFr1N3OZ+tJ9ZzXjc8kcnanhBsRviadObw0usI/qbqcJLAEeOKs7yeIBa+qOHt/UwQ== X-Received: by 10.159.39.39 with SMTP id a36mr233911uaa.86.1468304003498; Mon, 11 Jul 2016 23:13:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.54.196 with HTTP; Mon, 11 Jul 2016 23:13:23 -0700 (PDT) In-Reply-To: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> From: Russell Haley Date: Mon, 11 Jul 2016 23:13:23 -0700 Message-ID: Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 08:10:32 -0000 On Mon, Jul 11, 2016 at 9:15 AM, Karl Denninger wrote: > I have two PI2s on the same switch here doing quite-different things. > > One never shows network problems. The other one does this: > > .... > > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:08:12:1c > ugen0.4: at usbus0 > umass0: on usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:0:0: Attached to scbus0 > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number 00000000000000000000 > da0: 40.000MB/s transfers > da0: 476940MB (976773168 512 byte sectors) > da0: quirks=0x2 > random: unblocking device. > smsc0: chip 0xec00, rev. 0002 > ue0: link state changed to DOWN > ue0: link state changed to UP > ue0.2: link state changed to UP > ue0.3: link state changed to UP > ue0: link state changed to DOWN > ue0.2: link state changed to DOWN > ue0.3: link state changed to DOWN > ue0: link state changed to UP > ue0.2: link state changed to UP > ue0.3: link state changed to UP > ue0: link state changed to DOWN > ue0.2: link state changed to DOWN > ue0.3: link state changed to DOWN > ue0: link state changed to UP > ue0.2: link state changed to UP > ue0.3: link state changed to UP > ue0: link state changed to DOWN > ue0.2: link state changed to DOWN > ue0.3: link state changed to DOWN > ue0: link state changed to UP > ue0.2: link state changed to UP > ue0.3: link state changed to UP It's interesting that it flapped down (and then back up) three times and you have three interfaces. Does it do that consistently? Does it do it twice if there is only two interface (base plus a vlan)? Can you share the interface configuration source? Have you checked your system resources close to an expected flap to see if there is ballooning resources somewhere? Brendan Gregg has some fantastic tracing resources. Here are a couple of my favorites (not that I profess to know anything about dtrace...) http://www.brendangregg.com/USEmethod/use-freebsd.html http://www.brendangregg.com/dtrace.html https://forums.freebsd.org/threads/48802/ Russ > Every now and then (every hour or so) the interface flaps. If I plug a > USB interface in and use two network cords I *still* get the flapping. > This unit has very low (but non-zero) traffic on the network, while the > other actually has *more* traffic on the network yet is completely > stable. Since both are plugged into the same physical switch I doubt > the switch itself or its firmware is involved in this. > > The only difference I can see is that the one that flaps is using > vlans. Specifically, that machine is the network's dhcp server, and it > is on three different vlans (untagged and two tagged) so it can provide > addresses (and DNS services via unbound) to those VLAN interfaces. > > This appears to be somehow linked to the ue interface driver, because > another machine (Intel based) that is also on multiple vLANs via the em > driver does *not* flap. > > I don't know if this is actually arm related or not; it might not be if > Intel machines also use the "ue" driver, but it's very consistent on the > PI2 if I want to use vlan tags whether I have one or two interfaces (the > second via a USB adapter of course) in use or not. > > Other than the flapping the box appears to run fine; the flaps do, > however, sometimes stop reporting from the snmpd daemon so I have had to > stick a cron job out there to restart that on a schedule to prevent it > from interrupting reporting to my traffic management tools. Whether the > two are related is not known with certainty (but I suspect it is.) > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Tue Jul 12 08:30:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E0C6B931FA for ; Tue, 12 Jul 2016 08:30:14 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E46EB18E6 for ; Tue, 12 Jul 2016 08:30:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 37F1D1FE024; Tue, 12 Jul 2016 09:37:07 +0200 (CEST) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 To: Karl Denninger References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> <5f38e923-c1a1-8bb7-83cc-0de6404b6e47@denninger.net> Cc: "freebsd-arm@freebsd.org" From: Hans Petter Selasky Message-ID: Date: Tue, 12 Jul 2016 09:40:59 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5f38e923-c1a1-8bb7-83cc-0de6404b6e47@denninger.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 08:30:14 -0000 On 07/12/16 03:28, Karl Denninger wrote: > It *only* happens if I have the VLANs enabled. If I am running a single > network on an interface it's fine. Did you check the interface statistics? You can also try to enable debugging for the ethernet interface: "hw.usb.xxxx.debug=16" where xxxx is smsc or something like that. Are you sending very big packets? Did you try to set the MTU lower? --HPS From owner-freebsd-arm@freebsd.org Tue Jul 12 09:40:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F09E6B905A3 for ; Tue, 12 Jul 2016 09:40:14 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CA6B162A for ; Tue, 12 Jul 2016 09:40:13 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u6C9dxS0088556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 11:40:00 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u6C9drqs008779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jul 2016 11:39:53 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u6C9draQ036238; Tue, 12 Jul 2016 11:39:53 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u6C9drJu036237; Tue, 12 Jul 2016 11:39:53 +0200 (CEST) (envelope-from ticso) Date: Tue, 12 Jul 2016 11:39:53 +0200 From: Bernd Walter To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 Message-ID: <20160712093952.GA36104@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> <5f38e923-c1a1-8bb7-83cc-0de6404b6e47@denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f38e923-c1a1-8bb7-83cc-0de6404b6e47@denninger.net> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 09:40:15 -0000 On Mon, Jul 11, 2016 at 08:28:19PM -0500, Karl Denninger wrote: > > > On 7/11/2016 15:58, Bernd Walter wrote: > > On Mon, Jul 11, 2016 at 12:21:53PM -0500, Karl Denninger wrote: > >> On 7/11/2016 11:38, Hans Petter Selasky wrote: > >>> On 07/11/16 18:15, Karl Denninger wrote: > >>> Did you try to set any media options, like 10MBps instead of 100Mbps ? > >>> > >> Yes; it makes no difference. > >> > >>> What does ifconfig say? > >>> > >>> --HPS > >> No difference -- both are 100BaseTX connected. > >> > >> Machine with the problem: > >> % ifconfig ue0 > >> ue0: flags=8843 metric 0 mtu 1500 > >> options=80009 > >> ether b8:27:eb:08:12:1c > >> inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> nd6 options=29 > >> > >> > >> Machine without: > >> % ifconfig ue0 > >> ue0: flags=8843 metric 0 mtu 1500 > >> options=80009 > >> ether b8:27:eb:85:21:de > >> inet 192.168.1.214 netmask 0xffffff00 broadcast 192.168.1.255 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> nd6 options=29 > >> > >> The only difference I can see between them is that the one that exhibits > >> the flapping has vlans defined on the interface (which are working > >> normally.) > >> > >> Current code on both machines: > >> % uname -v > >> FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016 > >> karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/src/sys/RPI2 > >> > >> However, this has been an issue since the first 11-Current builds that > >> had RPI2 capability in them, so it's not version-dependent either. > > Sure it is not the board, powersupply, cable or switchport? > Yes, considering that I have (multiple times) swapped literally > everything (I have a bunch of PI2s here.) Just for grins and giggles I > did it again; swapped in a known working (no problems of this sort) > board, power supply that was used with it and network cable, and moved > it to a different switch port. > > The problem is still there. > > It *only* happens if I have the VLANs enabled. If I am running a single > network on an interface it's fine. > > Check if the red power LED on the Raspberry is on - it goes off under > > a certain supply voltage, although the board contiues to work. > Uh, the red LED only comes on during the boot sequence until the kernel > init's the GPIO on FreeBSD. You're thinking of Linux. I have a little > program that runs and slowly blinks the green LED though once started; > it's purpose is to provide a visible "system is running" indication. Strange - I'll have to test it, but I could have sworn that the power LED is independend from the OS. > > AFAIK all Raspberries have the same ethernet chip. > > Well - some earlier B (not B+) had used the 9512 instead of the 9514. > > Doesn't sound very logical if the same driver behaves different. > > A link down/up isn't something I would expect from the host controller > > causing this either. > > I also never had this problem on a Pi2. > How many people are running three networks (base plus two VLANs) on them? Not just Pi2 - I wonder how many do VLAN with USB ethernet at all? > >> I have been unable to find a way to log the *reason* the flap occurs > >> (e.g. nothing in the logs indicating why it thinks link-sense > >> disappeared, if it actually thinks it did, or if something in the code > >> performed what amounted to an interface reset.) > > Usually it is the PHY (which is integrated into the 9514), that detects > > and negotiates the link. > > The PHY runs on it's own internal state machine. > > The OS just gets informed, so that it can trigger some processing, > > such as updating the MAC for the negotiated link speed/duplex, logging > > the event, ... > I know. > > This has been an issue since the first RPI2 builds with this particular > configuration -- and still is. If I could figure out *why* it thinks > the PHY is going down I could track it down, but there's nothing I can > find that tells me that. The strange thing is tha VLANs have nothing to do with the link at all. The only obvious difference for the PHY is that it may see more traffic with more LANs. I currently have no Pi running FreeBSD accessable - I run my 24/7 FreeBSD ARM systems on Wandboards, but you ifconfig doewsn't show any VLAN offloading capabilities, so not an explanation either. > Oh, and the switch doesn't think it flapped either (!!); there is > nothing in the switch log about the link being lost and restored. So it is the receiver side which has a problem. I assume if you had packet loss you would have mentioned. Makes me wonder if this is really a link loss at all and not just some kind of missinformation. The PHY status is something, which usually gets polled, so maybe data corruption at any time may lead to this problem? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Tue Jul 12 14:33:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC0C5B93010 for ; Tue, 12 Jul 2016 14:33:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 620DE1C5F for ; Tue, 12 Jul 2016 14:33:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 3B970224DB2 for ; Tue, 12 Jul 2016 09:33:33 -0500 (CDT) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> <5f38e923-c1a1-8bb7-83cc-0de6404b6e47@denninger.net> <20160712093952.GA36104@cicely7.cicely.de> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: Date: Tue, 12 Jul 2016 09:33:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160712093952.GA36104@cicely7.cicely.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020100010806020700020309" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:33:35 -0000 This is a cryptographically signed message in MIME format. --------------ms020100010806020700020309 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/12/2016 04:39, Bernd Walter wrote: > On Mon, Jul 11, 2016 at 08:28:19PM -0500, Karl Denninger wrote: >> >> On 7/11/2016 15:58, Bernd Walter wrote: >>> On Mon, Jul 11, 2016 at 12:21:53PM -0500, Karl Denninger wrote: >>>> On 7/11/2016 11:38, Hans Petter Selasky wrote: >>>>> On 07/11/16 18:15, Karl Denninger wrote: >>>>> Did you try to set any media options, like 10MBps instead of 100Mbp= s ? >>>>> >>>> Yes; it makes no difference. >>>> >>>>> What does ifconfig say? >>>>> >>>>> --HPS >>>> No difference -- both are 100BaseTX connected. >>>> >>>> Machine with the problem: >>>> % ifconfig ue0 >>>> ue0: flags=3D8843 metric 0 m= tu 1500 >>>> options=3D80009 >>>> ether b8:27:eb:08:12:1c >>>> inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.25= 5 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> nd6 options=3D29 >>>> >>>> >>>> Machine without: >>>> % ifconfig ue0 >>>> ue0: flags=3D8843 metric 0 m= tu 1500 >>>> options=3D80009 >>>> ether b8:27:eb:85:21:de >>>> inet 192.168.1.214 netmask 0xffffff00 broadcast 192.168.1.25= 5 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>> nd6 options=3D29 >>>> >>>> The only difference I can see between them is that the one that exhi= bits >>>> the flapping has vlans defined on the interface (which are working >>>> normally.) >>>> >>>> Current code on both machines: >>>> % uname -v >>>> FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016 =20 >>>> karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBu= ild/src/sys/RPI2 >>>> >>>> However, this has been an issue since the first 11-Current builds th= at >>>> had RPI2 capability in them, so it's not version-dependent either. >>> Sure it is not the board, powersupply, cable or switchport? >> Yes, considering that I have (multiple times) swapped literally >> everything (I have a bunch of PI2s here.) Just for grins and giggles = I >> did it again; swapped in a known working (no problems of this sort) >> board, power supply that was used with it and network cable, and moved= >> it to a different switch port. >> >> The problem is still there. >> >> It *only* happens if I have the VLANs enabled. If I am running a sing= le >> network on an interface it's fine. >>> Check if the red power LED on the Raspberry is on - it goes off under= >>> a certain supply voltage, although the board contiues to work. >> Uh, the red LED only comes on during the boot sequence until the kerne= l >> init's the GPIO on FreeBSD. You're thinking of Linux. I have a littl= e >> program that runs and slowly blinks the green LED though once started;= >> it's purpose is to provide a visible "system is running" indication. > Strange - I'll have to test it, but I could have sworn that the power L= ED is > independend from the OS. > >>> AFAIK all Raspberries have the same ethernet chip. >>> Well - some earlier B (not B+) had used the 9512 instead of the 9514.= >>> Doesn't sound very logical if the same driver behaves different. >>> A link down/up isn't something I would expect from the host controlle= r >>> causing this either. >>> I also never had this problem on a Pi2. >> How many people are running three networks (base plus two VLANs) on th= em? > Not just Pi2 - I wonder how many do VLAN with USB ethernet at all? > >>>> I have been unable to find a way to log the *reason* the flap occurs= >>>> (e.g. nothing in the logs indicating why it thinks link-sense >>>> disappeared, if it actually thinks it did, or if something in the co= de >>>> performed what amounted to an interface reset.) >>> Usually it is the PHY (which is integrated into the 9514), that detec= ts >>> and negotiates the link. >>> The PHY runs on it's own internal state machine. >>> The OS just gets informed, so that it can trigger some processing, >>> such as updating the MAC for the negotiated link speed/duplex, loggin= g >>> the event, ... >> I know. >> >> This has been an issue since the first RPI2 builds with this particula= r >> configuration -- and still is. If I could figure out *why* it thinks >> the PHY is going down I could track it down, but there's nothing I can= >> find that tells me that. > The strange thing is tha VLANs have nothing to do with the link at all.= > The only obvious difference for the PHY is that it may see more traffic= > with more LANs. > I currently have no Pi running FreeBSD accessable - I run my 24/7 > FreeBSD ARM systems on Wandboards, but you ifconfig doewsn't show any > VLAN offloading capabilities, so not an explanation either. > >> Oh, and the switch doesn't think it flapped either (!!); there is >> nothing in the switch log about the link being lost and restored. > So it is the receiver side which has a problem. > I assume if you had packet loss you would have mentioned. > Makes me wonder if this is really a link loss at all and not just > some kind of missinformation. > The PHY status is something, which usually gets polled, so maybe > data corruption at any time may lead to this problem? > That's my assumption at this point; the claim of the flip is wrong.=20 But.... data corruption anywhere in a driver is very very bad! --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020100010806020700020309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTIxNDMzMDZaME8GCSqGSIb3DQEJBDFCBEDq rL+4IjvZupZ75XhwPl7PjtCAGSzG7S8nH09wzgJtik2+6Hm6jWqEa1iPm0ytSHI/zFzS29KI 6J8PEyHjUqKvMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAEDeZDtRo TMHwGgXWUN6FTseF2mJAvYqafMUAe56lMX1iQL02isWwaEN5+6USjRJx8qw56rVfPK/pu7Aa odAKRbpsnZ6n27Zynl2oggyuMnihKl3q+zxECaU/hbiyqAoPovk/aK5LF6syIZzkjiUfzSOM FIwznQkduiy+Td1vOeDljBiIEuflNLoKcD0xQm7bsG+kyaVSqeQWwR0DSBzPBFGGslDS02Va OWflDswJLhsmI91llxWtbi1+KlMvArAj3A7i95ipuUpdBf6/2vPgQJbzx5mx6VtC68nwNrAd PmUUcVeJfjreyR9hPkWh5XTyVCEeJ6XdTBHmxpfwuzML9lK2PK57GT0z/Vv5DBTH9hNZzvGZ SCSunZZlk45pgHqk9StFpsTHO+5ckXoFoudcTkw7VnN1qq0N4//UwmkPaCJuqCLbcRaVtQqu TJcqm9ikt8yZ3IVmEPUImcPrRjvAzN/DfqMBc9r07N2ktCmSJpt+N7GgfWDALoeruJOQyL66 XlSd+Se8tOp3Fwn2jAm3Pq+C8//QBn00k+ntHJdy+x0dthoTOm9OjWV60/VbXiSTQLNMLi4P cGUmCTMO1YFXmFHL19PuFg+mUDtJ4RPL9q/PMXuSfyJCq7Rp1s6yuSF5OES/yr9a1pP580O/ 4KkMxL2nmxFWYoMIqoZ9PvV5aAUAAAAAAAA= --------------ms020100010806020700020309-- From owner-freebsd-arm@freebsd.org Tue Jul 12 14:54:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91345B93933 for ; Tue, 12 Jul 2016 14:54:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 438EB1CF3 for ; Tue, 12 Jul 2016 14:54:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id C571D224EA8 for ; Tue, 12 Jul 2016 09:54:01 -0500 (CDT) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> <5f38e923-c1a1-8bb7-83cc-0de6404b6e47@denninger.net> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <3ad346b7-3c9f-05d6-a8cf-170a060051c9@denninger.net> Date: Tue, 12 Jul 2016 09:53:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020909060208030104060200" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:54:04 -0000 This is a cryptographically signed message in MIME format. --------------ms020909060208030104060200 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/12/2016 02:40, Hans Petter Selasky wrote: > On 07/12/16 03:28, Karl Denninger wrote: >> It *only* happens if I have the VLANs enabled. If I am running a sing= le >> network on an interface it's fine. > > Did you check the interface statistics? You can also try to enable > debugging for the ethernet interface: "hw.usb.xxxx.debug=3D16" where > xxxx is smsc or something like that. > > Are you sending very big packets? Did you try to set the MTU lower? > > --HPS There is no indication of trouble and the devices it is talking to are all MTU 1500, as is this unit..... root@IPGw:/etc/mail # netstat -i -b -n -I ue0 Name Mtu Network Address Ipkts Ierrs Idrop =20 Ibytes Opkts Oerrs Obytes Coll ue0 1500 b8:27:eb:be:e6:f8 174327 0 0=20 186606323 80559 0 6306399 0 ue0 - 192.168.1.0/2 192.168.1.200 134293 - -=20 181992609 77276 - 5049273 - root@IPGw:/etc/mail # netstat -i -b -n -I ue0.2 Name Mtu Network Address Ipkts Ierrs Idrop =20 Ibytes Opkts Oerrs Obytes Coll ue0.2 1500 b8:27:eb:be:e6:f8 25926 0 0 =20 1562248 1245 0 55796 0 ue0.2 - 70.169.168.0/ 70.169.168.97 76 - - =20 5634 1240 - 86378 - root@IPGw:/etc/mail # netstat -i -b -n -I ue0.3 Name Mtu Network Address Ipkts Ierrs Idrop =20 Ibytes Opkts Oerrs Obytes Coll ue0.3 1500 b8:27:eb:be:e6:f8 431 0 0 =20 74658 174 0 33422 0 ue0.3 - 192.168.4.0/2 192.168.4.200 85 - - =20 30260 85 - 27880 - Note that this CLAIMS no errors and very low traffic levels (as expected; this is just a DHCP server machine and an "emergency" way into the KVM on the servers if they blow up for some reason, as those KVMs are not exposed to the Internet for obvious reasons.) > It's interesting that it flapped down (and then back up) three times > and you have three interfaces. Does it do that consistently? Does it > do it twice if there is only two interface (base plus a vlan)? That's just a function of when I looked since boot. All three "flap" at the same time but the "flap" is fictitious in that the switch never sees the carrier drop on the port. Now, a day later, there are dozens of "flaps" in the dmesg output (in fact that's ALL that's there having rolled the buffer off!) > > Can you share the interface configuration source? Have you checked > your system resources close to an expected flap to see if there is > ballooning resources somewhere? Brendan Gregg has some fantastic > tracing resources. Here are a couple of my favorites (not that I > profess to know anything about dtrace...) Nothing complicated... ifconfig_ue0=3D"inet 192.168.1.200 netmask 255.255.255.0" # # VLAN for inside subnet # vlans_ue0=3D"2 3" ifconfig_ue0_2=3D"inet 70.169.168.97/25" ifconfig_ue0_3=3D"inet 192.168.4.200/24" defaultrouter=3D"70.169.168.1" That's it.... There's no system resource issue; the machine has plenty of RAM and mbufs; and no denied requests being logged anywhere. What this *looks like* is that something in the network stack thinks the interface state has gone down but it in fact has not (the switch doesn't see anything wrong.) As evidence that FreeBSD thinks it has, however, is that it *does* (sometimes) disrupt the snmpd client on this host and unless it is restarted it will stop talking to my network monitor for statistics, so I have to have a cron job that restarts snmpd every few hours or eventually I'll flat-line all the stats out of that host on the monitor console. The machine itself is extremely stable; it has run for months without a crash, only being interrupted by my intentional act (such as a software upgrade.) Then again it rarely is asked to do much since it's purpose in life is to provide a means of setting up a tunnel to internal KVMs in the event that one of the machines behind the Internet gateway (or the gateway itself!) blows up and requires attention from a remote (e.g. using ssh as a tunnel once you're signed into this machine.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020909060208030104060200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTIxNDUzMzRaME8GCSqGSIb3DQEJBDFCBEC9 BIe65fZFdhbJIM7n9ga6XdPnkV2Z4UmyuShcmZVrRQ4Hg4QwxNYQIl8e/bIz9VbrgKONejJU 9G2Gpb5DMPGIMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAtR8coDi0 ZR+2PE4tGSUyFjxRCOfvAvw6wxnkI+hEDaiei45n/0jj+Yjxt4IbkkMaa/daQjoVFJkj7nFT 2IQ6DszwuUSRBBc/bvhw0/OYQ2/xDjzrjJkXoKBCmAD2oDJ3GWXpVSeNNGhI0TjW/H0jwv7N g0WzFbYw5vi4wfXGLdYs9AgbADZYHfPOC6gTfkp2w1yMFaLqpyeMmchEy6MxeM6dPGPk1EAX 6LSRIe83hnUVlUMEZzJRMOKjtRcEWPtbY/wERRNus18Wvftu2yIBbWOexrKfel6/FSKSNmPd iSd+ZykOv5lqLy2q8xbfu8k6eVrlX0YEcuE8NaZa6DGWyX4IPllkph0fqnqf34aFPYSJd1az 75xW3MRgEN4xKNivt5kq3XxyCLTtvqu5Q3zYe495zddl1VTAAKugnKBUJEtCKALoMIiCNX8c /fIA0oce9uI4UjEe9Rx8DcvjrnEQBHlh5SW+KyhLbgb3F31k9ZVGwnKKmg1FO2dmPKSBTN+X zutWpaxccQUEUHhooxmheVHu2X0T17VGECjvoOUcpTNFHIGvpVUstg8/L0uDZadFdt2u8I7k +N9WK9UIhPzFgo28x297IhMK4vmbgQfZPj1lvApyvnqjjmgmUJbnSl7Ii1P5VwXHVcCwXJ5y Ws0ZCo/ETEr9x2W8Es58uor5m+wAAAAAAAA= --------------ms020909060208030104060200-- From owner-freebsd-arm@freebsd.org Tue Jul 12 14:55:06 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD7E6B9399B for ; Tue, 12 Jul 2016 14:55:06 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 94B151D63 for ; Tue, 12 Jul 2016 14:55:06 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 1ED211FE024; Tue, 12 Jul 2016 16:55:04 +0200 (CEST) Subject: Re: Old problem still present on 11-ALPHA1 - Pi2 To: Karl Denninger , "freebsd-arm@freebsd.org" References: <32ad8bb3-f0a6-c86b-1b23-aae9af4442ea@denninger.net> <62d7d041-2de5-639f-5c1e-76f9682e6cc8@selasky.org> <5682bff2-3033-194a-67bf-32ba0cdada37@denninger.net> <20160711205855.GC34367@cicely7.cicely.de> <5f38e923-c1a1-8bb7-83cc-0de6404b6e47@denninger.net> <20160712093952.GA36104@cicely7.cicely.de> From: Hans Petter Selasky Message-ID: <3d016e2b-d850-c135-7b39-16823a8aeecf@selasky.org> Date: Tue, 12 Jul 2016 16:58:55 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:55:06 -0000 On 07/12/16 16:33, Karl Denninger wrote: > That's my assumption at this point; the claim of the flip is wrong. > But.... data corruption anywhere in a driver is very very bad! Hi, usbdump -i usbusX -f Y.0 -s 65536 -vvv Will dump all the USB traffic on endpoint 0, which is used to communicate with the SMSC phy over USB. Try to turn on SMSC debugging first, and see if there are any errors or timeouts. --HPS From owner-freebsd-arm@freebsd.org Tue Jul 12 20:01:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F1DFB93DA4 for ; Tue, 12 Jul 2016 20:01:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3F011158D; Tue, 12 Jul 2016 20:01:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6B5E119C; Tue, 12 Jul 2016 20:01:39 +0000 (UTC) Date: Tue, 12 Jul 2016 20:01:38 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bdrewery@FreeBSD.org, slm@FreeBSD.org, cem@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1790940110.48.1468353699446.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3578 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 20:01:39 -0000 FreeBSD_HEAD_arm64 - Build #3578 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3578/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3578/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3578/console Change summaries: 302674 by bdrewery: META_MODE: Don't require filemon(4) for mergemaster(8)/etcupdate(8) New .meta files will be created without filemon data, but any future build that wants filemon data will force a rebuild due to the missing data due to use of bmake's .MAKE.MODE=missing-filemon=yes feature. Reported by: np Sponsored by: EMC / Isilon Storage Division MFC after: 3 days 302673 by slm: Use real values to calculate Max I/O size instead of guessing. Reviewed by: ken, scottl Approved by: ken, scottl, ambrisko (mentors) MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D7043 302671 by bdrewery: Create a TARGET_CPUARCH thing to go with MACHINE_CPUARCH. MFC after: 3 days Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D7160 302670 by bdrewery: Create one list of replacements for MACHINE_CPUARCH as MACHINE_CPUARCH_SUB. This also adds missing s/aarch64/arm64 to the sys.mk version and also adds back armv6hf for universe since it was added to the sys.mk version in r300438. MFC after: 3 days Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D7159 302669 by cem: ioat(4): Shrink using the correct timer Fix a typo introduced in r302352. Sponsored by: EMC / Isilon Storage Division The end of the build log: [...truncated 5019 lines...] ===> kerberos5/lib/libkadm5clnt (obj) --- obj_subdir_kerberos5/libexec --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/libexec/hpropd created for /usr/src/kerberos5/libexec/hpropd --- obj_subdir_kerberos5/libexec/kadmind --- ===> kerberos5/libexec/kadmind (obj) --- obj_subdir_gnu --- --- obj --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/addftinfo created for /usr/src/gnu/usr.bin/groff/src/utils/addftinfo --- obj_subdir_gnu/usr.bin/groff/src/utils/afmtodit --- ===> gnu/usr.bin/groff/src/utils/afmtodit (obj) --- obj_subdir_kerberos5 --- --- obj --- --- obj_subdir_kerberos5/lib --- --- obj --- --- obj_subdir_kerberos5/libexec --- /usr/obj/arm64.aarch64/usr/src/kerberos5/libexec/kadmind created for /usr/src/kerberos5/libexec/kadmind --- obj_subdir_kerberos5/lib --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libkadm5clnt created for /usr/src/kerberos5/lib/libkadm5clnt --- obj_subdir_kerberos5/libexec --- --- obj_subdir_kerberos5/libexec/kdc --- ===> kerberos5/libexec/kdc (obj) --- obj_subdir_lib --- --- obj --- --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib --- --- obj_subdir_kerberos5/lib/libkadm5srv --- ===> kerberos5/lib/libkadm5srv (obj) --- obj_subdir_gnu --- --- obj --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/afmtodit created for /usr/src/gnu/usr.bin/groff/src/utils/afmtodit --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/ttyio created for /usr/src/lib/libc/tests/ttyio --- obj_subdir_lib/libc/tests/locale --- ===> lib/libc/tests/locale (obj) --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/utils/hpftodit --- ===> gnu/usr.bin/groff/src/utils/hpftodit (obj) --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/libexec --- --- obj --- --- obj_subdir_gnu --- --- obj --- --- obj_subdir_kerberos5 --- /usr/obj/arm64.aarch64/usr/src/kerberos5/libexec/kdc created for /usr/src/kerberos5/libexec/kdc --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/hpftodit created for /usr/src/gnu/usr.bin/groff/src/utils/hpftodit --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib --- --- obj --- --- obj_subdir_kerberos5/libexec --- --- obj_subdir_kerberos5/libexec/kdigest --- ===> kerberos5/libexec/kdigest (obj) --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/utils/indxbib --- ===> gnu/usr.bin/groff/src/utils/indxbib (obj) --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libkadm5srv created for /usr/src/kerberos5/lib/libkadm5srv --- obj_subdir_kerberos5/lib/libkrb5 --- ===> kerberos5/lib/libkrb5 (obj) --- obj_subdir_gnu --- --- obj --- --- obj_subdir_lib --- --- obj --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/locale created for /usr/src/lib/libc/tests/locale --- obj_subdir_lib/libc/tests/ssp --- ===> lib/libc/tests/ssp (obj) --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/indxbib created for /usr/src/gnu/usr.bin/groff/src/utils/indxbib --- obj_subdir_gnu/usr.bin/groff/src/utils/lkbib --- ===> gnu/usr.bin/groff/src/utils/lkbib (obj) --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/libexec --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/libexec/kdigest created for /usr/src/kerberos5/libexec/kdigest --- obj_subdir_kerberos5/libexec/kfd --- ===> kerberos5/libexec/kfd (obj) --- obj_subdir_gnu --- --- obj --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/lkbib created for /usr/src/gnu/usr.bin/groff/src/utils/lkbib --- obj_subdir_gnu/usr.bin/groff/src/utils/lookbib --- ===> gnu/usr.bin/groff/src/utils/lookbib (obj) --- obj_subdir_kerberos5 --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/libexec/kfd created for /usr/src/kerberos5/libexec/kfd --- obj_subdir_kerberos5/libexec/kimpersonate --- ===> kerberos5/libexec/kimpersonate (obj) --- obj_subdir_gnu --- --- obj --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/lookbib created for /usr/src/gnu/usr.bin/groff/src/utils/lookbib --- obj_subdir_gnu/usr.bin/groff/src/utils/pfbtops --- ===> gnu/usr.bin/groff/src/utils/pfbtops (obj) --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib --- --- obj --- --- obj_subdir_lib --- --- obj --- --- obj_subdir_kerberos5 --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libkrb5 created for /usr/src/kerberos5/lib/libkrb5 --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/ssp created for /usr/src/lib/libc/tests/ssp --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib/libroken --- ===> kerberos5/lib/libroken (obj) --- obj_subdir_lib --- --- obj --- --- obj --- --- obj_subdir_lib/msun --- ===> lib/msun (obj) bmake[4]: "/usr/src/lib/msun/Makefile" line 22: Could not find arm64/Makefile.inc bmake[4]: "/usr/src/lib/msun/Makefile" line 31: Malformed conditional (${LDBL_PREC} == 64) --- obj_subdir_gnu --- --- obj --- --- obj_subdir_lib --- bmake[4]: "/usr/src/lib/msun/Makefile" line 99: Malformed conditional (${LDBL_PREC} != 53) --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/pfbtops created for /usr/src/gnu/usr.bin/groff/src/utils/pfbtops --- obj_subdir_gnu/usr.bin/groff/src/utils/tfmtodit --- ===> gnu/usr.bin/groff/src/utils/tfmtodit (obj) --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/libexec --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/libexec/kimpersonate created for /usr/src/kerberos5/libexec/kimpersonate --- obj_subdir_kerberos5/libexec/kpasswdd --- ===> kerberos5/libexec/kpasswdd (obj) --- obj_subdir_kerberos5/lib --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libroken created for /usr/src/kerberos5/lib/libroken --- obj_subdir_gnu --- --- obj --- --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib/libsl --- ===> kerberos5/lib/libsl (obj) --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/tfmtodit created for /usr/src/gnu/usr.bin/groff/src/utils/tfmtodit --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib/libvers --- ===> kerberos5/lib/libvers (obj) --- obj_subdir_kerberos5/lib/libsl --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libsl created for /usr/src/kerberos5/lib/libsl --- obj_subdir_kerberos5/libexec --- --- obj_subdir_kerberos5/libexec/kcm --- ===> kerberos5/libexec/kcm (obj) --- obj_subdir_kerberos5/libexec/kpasswdd --- --- obj --- --- obj_subdir_kerberos5/lib --- --- obj_subdir_kerberos5/lib/libvers --- --- obj --- --- obj_subdir_kerberos5/libexec --- /usr/obj/arm64.aarch64/usr/src/kerberos5/libexec/kpasswdd created for /usr/src/kerberos5/libexec/kpasswdd --- obj_subdir_kerberos5/lib --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libvers created for /usr/src/kerberos5/lib/libvers --- obj_subdir_kerberos5/tools --- ===> kerberos5/tools (obj) --- obj_subdir_kerberos5/lib --- --- obj_subdir_kerberos5/lib/libkdc --- ===> kerberos5/lib/libkdc (obj) --- obj_subdir_lib --- bmake[4]: Fatal errors encountered -- cannot continue bmake[4]: stopped in /usr/src/lib/msun --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/libexec --- --- obj_subdir_kerberos5/libexec/kcm --- --- obj --- --- obj_subdir_lib --- *** [obj_subdir_lib/msun] Error code 1 bmake[3]: stopped in /usr/src/lib 1 error bmake[3]: stopped in /usr/src/lib *** [obj_subdir_lib] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_kerberos5 --- /usr/obj/arm64.aarch64/usr/src/kerberos5/libexec/kcm created for /usr/src/kerberos5/libexec/kcm A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/kerberos5/libexec/kcm *** [obj_subdir_kerberos5/libexec/kcm] Error code 2 bmake[4]: stopped in /usr/src/kerberos5/libexec 1 error bmake[4]: stopped in /usr/src/kerberos5/libexec *** [obj_subdir_kerberos5/libexec] Error code 2 bmake[3]: stopped in /usr/src/kerberos5 --- obj_subdir_kerberos5/lib --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/kerberos5/lib/libkdc *** [obj_subdir_kerberos5/lib/libkdc] Error code 2 bmake[4]: stopped in /usr/src/kerberos5/lib 1 error bmake[4]: stopped in /usr/src/kerberos5/lib *** [obj_subdir_kerberos5/lib] Error code 2 bmake[3]: stopped in /usr/src/kerberos5 --- obj_subdir_kerberos5/tools --- A failure has been detected in another branch of the parallel make bmake[4]: stopped in /usr/src/kerberos5/tools *** [obj_subdir_kerberos5/tools] Error code 2 bmake[3]: stopped in /usr/src/kerberos5 3 errors bmake[3]: stopped in /usr/src/kerberos5 *** [obj_subdir_kerberos5] Error code 2 bmake[2]: stopped in /usr/src 2 errors bmake[2]: stopped in /usr/src *** [_obj] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson3187478068895609339.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::102:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Tue Jul 12 21:58:10 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6645B9379E for ; Tue, 12 Jul 2016 21:58:10 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AAC471C86; Tue, 12 Jul 2016 21:58:10 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9F92B1A0; Tue, 12 Jul 2016 21:58:10 +0000 (UTC) Date: Tue, 12 Jul 2016 21:58:09 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: cem@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1459347688.50.1468360690660.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1790940110.48.1468353699446.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1790940110.48.1468353699446.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3579 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 21:58:10 -0000 FreeBSD_HEAD_arm64 - Build #3579 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3579/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3579/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3579/console Change summaries: 302677 by cem: ioat(4): Print some more useful information about the ring from ddb "show ioat" The end of the build log: [...truncated 5073 lines...] --- obj --- --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/utils/afmtodit --- ===> gnu/usr.bin/groff/src/utils/afmtodit (obj) --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/gen/posix_spawn created for /usr/src/lib/libc/tests/gen/posix_spawn --- obj --- --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/tests --- ===> gnu/usr.bin/tests (obj) --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libkafs5 created for /usr/src/kerberos5/lib/libkafs5 --- obj_subdir_kerberos5/usr.bin --- ===> kerberos5/usr.bin (obj) --- obj_subdir_lib --- --- obj_subdir_lib/libc/tests/hash --- --- obj --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/hash created for /usr/src/lib/libc/tests/hash --- obj_subdir_lib/libc/tests/iconv --- ===> lib/libc/tests/iconv (obj) --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff --- --- obj --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/afmtodit created for /usr/src/gnu/usr.bin/groff/src/utils/afmtodit --- obj_subdir_gnu/usr.bin/groff/src/utils/hpftodit --- ===> gnu/usr.bin/groff/src/utils/hpftodit (obj) --- obj_subdir_gnu/usr.bin/tests --- --- obj --- --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/usr.bin/hxtool --- ===> kerberos5/usr.bin/hxtool (obj) --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/tests created for /usr/src/gnu/usr.bin/tests --- obj_subdir_gnu/usr.bin/groff --- --- obj_subdir_gnu/usr.bin/groff/tmac --- ===> gnu/usr.bin/groff/tmac (obj) --- obj_subdir_lib --- --- obj --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/iconv created for /usr/src/lib/libc/tests/iconv --- obj_subdir_lib/libc/tests/inet --- ===> lib/libc/tests/inet (obj) --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src --- --- obj --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/hpftodit created for /usr/src/gnu/usr.bin/groff/src/utils/hpftodit --- obj_subdir_gnu/usr.bin/groff/src/utils/indxbib --- ===> gnu/usr.bin/groff/src/utils/indxbib (obj) --- obj_subdir_gnu/usr.bin/groff/tmac --- --- obj --- --- obj_subdir_lib --- --- obj --- --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/tmac created for /usr/src/gnu/usr.bin/groff/tmac --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/inet created for /usr/src/lib/libc/tests/inet --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src --- --- obj --- --- obj_subdir_lib --- --- obj_subdir_lib/msun --- ===> lib/msun (obj) --- obj_subdir_lib/libc --- --- obj_subdir_lib/libc/tests/net --- ===> lib/libc/tests/net (obj) --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/indxbib created for /usr/src/gnu/usr.bin/groff/src/utils/indxbib --- obj_subdir_kerberos5 --- --- obj --- --- obj_subdir_lib --- --- obj_subdir_lib/msun --- bmake[4]: "/usr/src/lib/msun/Makefile" line 22: Could not find arm64/Makefile.inc bmake[4]: "/usr/src/lib/msun/Makefile" line 31: Malformed conditional (${LDBL_PREC} == 64) --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/utils/lkbib --- ===> gnu/usr.bin/groff/src/utils/lkbib (obj) --- obj_subdir_lib --- bmake[4]: "/usr/src/lib/msun/Makefile" line 99: Malformed conditional (${LDBL_PREC} != 53) --- obj_subdir_kerberos5 --- /usr/obj/arm64.aarch64/usr/src/kerberos5/usr.bin/hxtool created for /usr/src/kerberos5/usr.bin/hxtool --- obj_subdir_kerberos5/usr.bin/kadmin --- ===> kerberos5/usr.bin/kadmin (obj) --- obj_subdir_gnu --- --- obj --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/lkbib created for /usr/src/gnu/usr.bin/groff/src/utils/lkbib --- obj_subdir_gnu/usr.bin/groff/src/utils/lookbib --- ===> gnu/usr.bin/groff/src/utils/lookbib (obj) --- obj_subdir_kerberos5 --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/usr.bin/kadmin created for /usr/src/kerberos5/usr.bin/kadmin --- obj_subdir_kerberos5/usr.bin/kcc --- ===> kerberos5/usr.bin/kcc (obj) --- obj_subdir_lib --- --- obj_subdir_lib/libc --- --- obj --- --- obj_subdir_gnu --- --- obj --- --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/net created for /usr/src/lib/libc/tests/net --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/lookbib created for /usr/src/gnu/usr.bin/groff/src/utils/lookbib --- obj_subdir_lib --- --- obj_subdir_lib/libc/tests/nss --- ===> lib/libc/tests/nss (obj) --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/utils/pfbtops --- ===> gnu/usr.bin/groff/src/utils/pfbtops (obj) --- obj_subdir_kerberos5 --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/usr.bin/kcc created for /usr/src/kerberos5/usr.bin/kcc --- obj_subdir_gnu --- --- obj --- --- obj_subdir_lib --- --- obj --- --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/usr.bin/kdestroy --- ===> kerberos5/usr.bin/kdestroy (obj) --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/utils/pfbtops created for /usr/src/gnu/usr.bin/groff/src/utils/pfbtops --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/nss created for /usr/src/lib/libc/tests/nss --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/utils/tfmtodit --- ===> gnu/usr.bin/groff/src/utils/tfmtodit (obj) --- obj_subdir_lib --- --- obj_subdir_lib/msun --- bmake[4]: Fatal errors encountered -- cannot continue bmake[4]: stopped in /usr/src/lib/msun *** [obj_subdir_lib/msun] Error code 1 bmake[3]: stopped in /usr/src/lib --- obj_subdir_lib/libc --- --- obj_subdir_lib/libc/tests/regex --- ===> lib/libc/tests/regex (obj) --- obj_subdir_kerberos5 --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/kerberos5/usr.bin/kdestroy *** [obj_subdir_kerberos5/usr.bin/kdestroy] Error code 2 bmake[4]: stopped in /usr/src/kerberos5/usr.bin 1 error bmake[4]: stopped in /usr/src/kerberos5/usr.bin *** [obj_subdir_kerberos5/usr.bin] Error code 2 bmake[3]: stopped in /usr/src/kerberos5 1 error bmake[3]: stopped in /usr/src/kerberos5 *** [obj_subdir_kerberos5] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_gnu --- A failure has been detected in another branch of the parallel make bmake[8]: stopped in /usr/src/gnu/usr.bin/groff/src/utils/tfmtodit *** [obj_subdir_gnu/usr.bin/groff/src/utils/tfmtodit] Error code 2 bmake[7]: stopped in /usr/src/gnu/usr.bin/groff/src/utils 1 error bmake[7]: stopped in /usr/src/gnu/usr.bin/groff/src/utils *** [obj_subdir_gnu/usr.bin/groff/src/utils] Error code 2 bmake[6]: stopped in /usr/src/gnu/usr.bin/groff/src 1 error bmake[6]: stopped in /usr/src/gnu/usr.bin/groff/src *** [obj_subdir_gnu/usr.bin/groff/src] Error code 2 bmake[5]: stopped in /usr/src/gnu/usr.bin/groff 1 error bmake[5]: stopped in /usr/src/gnu/usr.bin/groff *** [obj_subdir_gnu/usr.bin/groff] Error code 2 bmake[4]: stopped in /usr/src/gnu/usr.bin 1 error bmake[4]: stopped in /usr/src/gnu/usr.bin *** [obj_subdir_gnu/usr.bin] Error code 2 bmake[3]: stopped in /usr/src/gnu 1 error bmake[3]: stopped in /usr/src/gnu *** [obj_subdir_gnu] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_lib --- A failure has been detected in another branch of the parallel make bmake[6]: stopped in /usr/src/lib/libc/tests/regex *** [obj_subdir_lib/libc/tests/regex] Error code 2 bmake[5]: stopped in /usr/src/lib/libc/tests 1 error bmake[5]: stopped in /usr/src/lib/libc/tests *** [obj_subdir_lib/libc/tests] Error code 2 bmake[4]: stopped in /usr/src/lib/libc 1 error bmake[4]: stopped in /usr/src/lib/libc *** [obj_subdir_lib/libc] Error code 2 bmake[3]: stopped in /usr/src/lib 2 errors bmake[3]: stopped in /usr/src/lib *** [obj_subdir_lib] Error code 2 bmake[2]: stopped in /usr/src 3 errors bmake[2]: stopped in /usr/src *** [_obj] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson197271431167184000.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Tue Jul 12 22:05:00 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84A6BB93963 for ; Tue, 12 Jul 2016 22:05:00 +0000 (UTC) (envelope-from cepispbru@vh91.sweb.ru) Received: from vh91.sweb.ru (unknown [IPv6:2a02:408:7722:1:77:222:56:223]) (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 48D01120D for ; Tue, 12 Jul 2016 22:04:59 +0000 (UTC) (envelope-from cepispbru@vh91.sweb.ru) Received: from cepispbru by vh91.sweb.ru with local (Exim 4.85_2) (envelope-from ) id 1bN5nU-001f3J-R8 for freebsd-arm@freebsd.org; Wed, 13 Jul 2016 01:04:56 +0300 To: freebsd-arm@freebsd.org Subject: Unable to deliver your item, #00741140 Date: Wed, 13 Jul 2016 01:04:56 +0300 From: "FedEx International Next Flight" Reply-To: "FedEx International Next Flight" Message-ID: <01b2bd6d0fc124cfe4e6189a04ee6edb@cepi-spb.ru> X-Priority: 3 MIME-Version: 1.0 X-Sender-Uid: 10413 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 22:05:00 -0000 Dear Customer, Your parcel has arrived at July 09. Courier was unable to deliver the parcel to you. Delivery Label is attached to this email. Warm regards, Willard Brennan, FedEx Station Manager. From owner-freebsd-arm@freebsd.org Tue Jul 12 23:57:12 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2415B978D7 for ; Tue, 12 Jul 2016 23:57:12 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D53A01BE9; Tue, 12 Jul 2016 23:57:12 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E34851A4; Tue, 12 Jul 2016 23:57:12 +0000 (UTC) Date: Tue, 12 Jul 2016 23:57:11 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: cem@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <223822942.52.1468367832938.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1459347688.50.1468360690660.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1459347688.50.1468360690660.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3580 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 23:57:13 -0000 FreeBSD_HEAD_arm64 - Build #3580 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3580/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3580/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3580/console Change summaries: 302686 by cem: ioat(4): Check ring links at grow/shrink in INVARIANTS 302685 by cem: ioat(4): Add KTR trace for ioat_reset_hw 302684 by cem: ioat(4): Enhance KTR logging for descriptor completions 302683 by cem: ioat(4): Assert against ring underflow 302682 by cem: ioat_reserve_space: Recheck quiescing flag after dropping submit lock Fix a minor bound check error while here (ring can only hold 1 << MAX_ORDER - 1 entries). 302681 by cem: ioat(4): Remove force_hw_error sysctl; it does not work reliably 302680 by cem: ioat(4): Export HW capabilities to consumers 302679 by cem: ioat(4): Submitters pick up a shovel if queue is too full Before attempting to grow the ring. 302678 by cem: ioat(4): Don't shrink ring if active The end of the build log: [...truncated 5189 lines...] --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/preproc/tbl --- ===> gnu/usr.bin/groff/src/preproc/tbl (obj) --- obj_subdir_kerberos5 --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libkdc created for /usr/src/kerberos5/lib/libkdc --- obj_subdir_kerberos5/lib/libwind --- ===> kerberos5/lib/libwind (obj) --- obj_subdir_gnu --- --- obj --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/preproc/tbl created for /usr/src/gnu/usr.bin/groff/src/preproc/tbl --- obj_subdir_gnu/usr.bin/groff/src/roff --- ===> gnu/usr.bin/groff/src/roff (obj) --- obj_subdir_rescue --- --- obj_crunchdir_cat --- cd /usr/src/rescue/rescue/../../bin/cat && MK_AUTO_OBJ=no MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 MAKEOBJDIRPREFIX=/usr/obj/arm64.aarch64/usr/src/rescue/rescue /usr/obj/usr/src/make.amd64/bmake DIRPRFX=rescue/rescue/cat/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE MK_AUTO_OBJ=no obj --- obj_subdir_lib --- --- obj --- --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/roff/groff --- ===> gnu/usr.bin/groff/src/roff/groff (obj) --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libc/tests/ssp created for /usr/src/lib/libc/tests/ssp --- obj --- --- obj --- --- obj_subdir_kerberos5 --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libwind created for /usr/src/kerberos5/lib/libwind --- obj_subdir_lib --- --- obj_subdir_lib/libelf --- ===> lib/libelf (obj) --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib/libheimbase --- ===> kerberos5/lib/libheimbase (obj) --- obj_subdir_rescue --- --- obj --- /usr/obj/arm64.aarch64/usr/src/rescue/rescue/usr/src/bin/cat created for /usr/src/bin/cat --- obj_subdir_gnu --- --- obj --- --- obj_subdir_rescue --- --- obj_crunchdir_chflags --- cd /usr/src/rescue/rescue/../../bin/chflags && MK_AUTO_OBJ=no MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 MAKEOBJDIRPREFIX=/usr/obj/arm64.aarch64/usr/src/rescue/rescue /usr/obj/usr/src/make.amd64/bmake DIRPRFX=rescue/rescue/chflags/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE MK_AUTO_OBJ=no obj --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/roff/groff created for /usr/src/gnu/usr.bin/groff/src/roff/groff --- obj_subdir_gnu/usr.bin/groff/src/roff/grog --- ===> gnu/usr.bin/groff/src/roff/grog (obj) --- obj_subdir_rescue --- --- obj --- /usr/obj/arm64.aarch64/usr/src/rescue/rescue/usr/src/bin/chflags created for /usr/src/bin/chflags --- obj_subdir_gnu --- --- obj --- --- obj_subdir_rescue --- --- obj_crunchdir_chio --- cd /usr/src/rescue/rescue/../../bin/chio && MK_AUTO_OBJ=no MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 MAKEOBJDIRPREFIX=/usr/obj/arm64.aarch64/usr/src/rescue/rescue /usr/obj/usr/src/make.amd64/bmake DIRPRFX=rescue/rescue/chio/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE MK_AUTO_OBJ=no obj --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/roff/grog created for /usr/src/gnu/usr.bin/groff/src/roff/grog --- obj_subdir_kerberos5 --- --- obj --- --- obj_subdir_lib --- --- obj --- --- obj_subdir_gnu --- --- obj_subdir_gnu/usr.bin/groff/src/roff/nroff --- ===> gnu/usr.bin/groff/src/roff/nroff (obj) --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libelf created for /usr/src/lib/libelf --- obj_subdir_kerberos5 --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libheimbase created for /usr/src/kerberos5/lib/libheimbase --- obj_subdir_lib --- /usr/obj/arm64.aarch64/usr/src/lib/libelf/sys created for /usr/src/lib/libelf --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib/libheimipcc --- ===> kerberos5/lib/libheimipcc (obj) --- obj_subdir_lib --- --- obj_subdir_lib/msun --- ===> lib/msun (obj) bmake[4]: "/usr/src/lib/msun/Makefile" line 22: Could not find arm64/Makefile.inc bmake[4]: "/usr/src/lib/msun/Makefile" line 31: Malformed conditional (${LDBL_PREC} == 64) bmake[4]: "/usr/src/lib/msun/Makefile" line 99: Malformed conditional (${LDBL_PREC} != 53) --- obj_subdir_rescue --- --- obj --- /usr/obj/arm64.aarch64/usr/src/rescue/rescue/usr/src/bin/chio created for /usr/src/bin/chio --- obj_subdir_gnu --- --- obj --- --- obj_subdir_rescue --- --- obj_crunchdir_chmod --- cd /usr/src/rescue/rescue/../../bin/chmod && MK_AUTO_OBJ=no MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 MAKEOBJDIRPREFIX=/usr/obj/arm64.aarch64/usr/src/rescue/rescue /usr/obj/usr/src/make.amd64/bmake DIRPRFX=rescue/rescue/chmod/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE MK_AUTO_OBJ=no obj --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/roff/nroff created for /usr/src/gnu/usr.bin/groff/src/roff/nroff --- obj_subdir_gnu/usr.bin/groff/src/roff/psroff --- ===> gnu/usr.bin/groff/src/roff/psroff (obj) --- obj_subdir_kerberos5 --- --- obj --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libheimipcc created for /usr/src/kerberos5/lib/libheimipcc --- obj_subdir_kerberos5/lib/libheimipcs --- ===> kerberos5/lib/libheimipcs (obj) --- obj_subdir_rescue --- --- obj --- /usr/obj/arm64.aarch64/usr/src/rescue/rescue/usr/src/bin/chmod created for /usr/src/bin/chmod --- obj_subdir_gnu --- --- obj --- --- obj_subdir_rescue --- --- obj_crunchdir_cp --- cd /usr/src/rescue/rescue/../../bin/cp && MK_AUTO_OBJ=no MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 MAKEOBJDIRPREFIX=/usr/obj/arm64.aarch64/usr/src/rescue/rescue /usr/obj/usr/src/make.amd64/bmake DIRPRFX=rescue/rescue/cp/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE MK_AUTO_OBJ=no obj --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/roff/psroff created for /usr/src/gnu/usr.bin/groff/src/roff/psroff --- obj_subdir_gnu/usr.bin/groff/src/roff/troff --- ===> gnu/usr.bin/groff/src/roff/troff (obj) --- obj_subdir_rescue --- --- obj --- --- obj_subdir_kerberos5 --- --- obj --- --- obj_subdir_rescue --- /usr/obj/arm64.aarch64/usr/src/rescue/rescue/usr/src/bin/cp created for /usr/src/bin/cp --- obj_subdir_kerberos5 --- /usr/obj/arm64.aarch64/usr/src/kerberos5/lib/libheimipcs created for /usr/src/kerberos5/lib/libheimipcs --- obj_subdir_gnu --- --- obj --- --- obj_subdir_rescue --- --- obj_crunchdir_date --- cd /usr/src/rescue/rescue/../../bin/date && MK_AUTO_OBJ=no MK_TESTS=no UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 MAKEOBJDIRPREFIX=/usr/obj/arm64.aarch64/usr/src/rescue/rescue /usr/obj/usr/src/make.amd64/bmake DIRPRFX=rescue/rescue/date/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE MK_AUTO_OBJ=no obj --- obj_subdir_kerberos5 --- --- obj_subdir_kerberos5/lib/libkafs5 --- ===> kerberos5/lib/libkafs5 (obj) --- obj_subdir_gnu --- /usr/obj/arm64.aarch64/usr/src/gnu/usr.bin/groff/src/roff/troff created for /usr/src/gnu/usr.bin/groff/src/roff/troff --- obj_subdir_gnu/usr.bin/groff/src/utils --- ===> gnu/usr.bin/groff/src/utils (obj) --- obj_subdir_gnu/usr.bin/groff/src/utils/addftinfo --- ===> gnu/usr.bin/groff/src/utils/addftinfo (obj) --- obj_subdir_lib --- bmake[4]: Fatal errors encountered -- cannot continue bmake[4]: stopped in /usr/src/lib/msun *** [obj_subdir_lib/msun] Error code 1 bmake[3]: stopped in /usr/src/lib 1 error bmake[3]: stopped in /usr/src/lib *** [obj_subdir_lib] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_rescue --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/bin/date *** [obj_crunchdir_date] Error code 2 bmake[4]: stopped in /usr/src/rescue/rescue 1 error bmake[4]: stopped in /usr/src/rescue/rescue *** [obj_subdir_rescue/rescue] Error code 2 bmake[3]: stopped in /usr/src/rescue 1 error bmake[3]: stopped in /usr/src/rescue *** [obj_subdir_rescue] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_kerberos5 --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/src/kerberos5/lib/libkafs5 *** [obj_subdir_kerberos5/lib/libkafs5] Error code 2 bmake[4]: stopped in /usr/src/kerberos5/lib 1 error bmake[4]: stopped in /usr/src/kerberos5/lib *** [obj_subdir_kerberos5/lib] Error code 2 bmake[3]: stopped in /usr/src/kerberos5 1 error bmake[3]: stopped in /usr/src/kerberos5 *** [obj_subdir_kerberos5] Error code 2 bmake[2]: stopped in /usr/src --- obj_subdir_gnu --- A failure has been detected in another branch of the parallel make bmake[8]: stopped in /usr/src/gnu/usr.bin/groff/src/utils/addftinfo *** [obj_subdir_gnu/usr.bin/groff/src/utils/addftinfo] Error code 2 bmake[7]: stopped in /usr/src/gnu/usr.bin/groff/src/utils 1 error bmake[7]: stopped in /usr/src/gnu/usr.bin/groff/src/utils *** [obj_subdir_gnu/usr.bin/groff/src/utils] Error code 2 bmake[6]: stopped in /usr/src/gnu/usr.bin/groff/src 1 error bmake[6]: stopped in /usr/src/gnu/usr.bin/groff/src *** [obj_subdir_gnu/usr.bin/groff/src] Error code 2 bmake[5]: stopped in /usr/src/gnu/usr.bin/groff 1 error bmake[5]: stopped in /usr/src/gnu/usr.bin/groff *** [obj_subdir_gnu/usr.bin/groff] Error code 2 bmake[4]: stopped in /usr/src/gnu/usr.bin 1 error bmake[4]: stopped in /usr/src/gnu/usr.bin *** [obj_subdir_gnu/usr.bin] Error code 2 bmake[3]: stopped in /usr/src/gnu 1 error bmake[3]: stopped in /usr/src/gnu *** [obj_subdir_gnu] Error code 2 bmake[2]: stopped in /usr/src 4 errors bmake[2]: stopped in /usr/src *** [_obj] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson892645218184449517.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::102:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Wed Jul 13 02:16:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE84DB93E2B for ; Wed, 13 Jul 2016 02:16:34 +0000 (UTC) (envelope-from freebsd-arm@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 6AA671C2D for ; Wed, 13 Jul 2016 02:16:33 +0000 (UTC) (envelope-from freebsd-arm@herveybayaustralia.com.au) Received: from [192.168.0.177] (laptop3.herveybayaustralia.com.au [192.168.0.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id C7F6561FF5 for ; Wed, 13 Jul 2016 12:16:23 +1000 (EST) Message-ID: <5785A475.1070808@herveybayaustralia.com.au> Date: Wed, 13 Jul 2016 12:16:21 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: [BUMP]: Re: Raspberry PI 3 - initial newb - help! References: <5781B068.1020107@herveybayaustralia.com.au> In-Reply-To: <5781B068.1020107@herveybayaustralia.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 02:16:35 -0000 Still struggling a bit with u-boot concepts: rpi boots, looks in the mbr with fat partition for u-boot. U-boot is not specifically in any address as such so it has to actually look for it. So why does ubldr require a start address? Which address is it looking for? And how do I find it? Until I figure that out I can't compile it can I? To clarify also, the dtb is configured in the config for u-boot? Then u-boot passes that in to ubldr? Or can't FBSD handle that at this stage? And has anyone tried the display connection onboard at all? Would that work better than the hdmi by actually displaying processes occurring like the u-boot? On 10/07/2016 12:18, Da Rock wrote: > Ok, so I got my hands on a RPi3 knowing that things aren't probably > going to work straight off. Never worked with arm before, but trying > to move towards the "future" :) rather than keep buying laptops. > Haven't had much success with qemu as yet, and so thought hardware > might be better and more fulfilling anyway. And they finally came in > stock locally as well, so grabbed it while I could. > > Booted raspbian straight off to get a handle on what control should > look like, and got a nice little system with a rainbow icon in the > corner (?). Grabbed the output from dmesg and such and kept a copy on > my laptop. > > My next research was to try building freebsd for arm/rpi3. Got current > (10.x wouldn't do it) and built a distribution for arm64. So far so > good - cross compile works fine with clang. (Remember, complete newb > with cross compiling, arm, all that - worked on x86 only) > > I then looked at the booting process, and u-boot. Sounds like a > mindfield.... fun. Also came across crotchet, which as I understand > has all this scripted, but for my purposes I need to actually > understand the steps rather than have the script do it for me at this > stage. So not real helpful at this point - if someone could point out > the steps taken would be good. > > So I then checked out the 10.3 rpi img from the FreeBSD downloads, and > tried booting. NG. All I get is a rainbow test screen. Same with a > 11-current version too. > > I post this here so I can get some pointers and advice on how to > continue in my research and possibly getting my rpi3 to run. > > It looks to me that the u-boot is grabbing the wrong address and so > not booting the imgs properly. > > Question: if the u-boot use loader to boot, then does that mean that > once set there is no need to rebuild all as such - a kernel change can > be initiated without hiccup? In other words, u-boot and loader stay in > place, but nearly all can change around that? > > I'm also noting the FDT, and I have the actual dtb file for the rpi3, > but how would I use it? Am I right in assuming the file is platform > neutral, and so will work for linux and FreeBSD? > > Is there any good tutorials on using u-boot and configuring it correctly? > > And the main reason why I could never get qemu to work with arm was it > kept asking for a kernel file - is that meant to be the u-boot file then? > > Cheers > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Jul 13 03:05:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 623E5B97757 for ; Wed, 13 Jul 2016 03:05:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 48D5F16C6; Wed, 13 Jul 2016 03:05:35 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5D6C41AA; Wed, 13 Jul 2016 03:05:35 +0000 (UTC) Date: Wed, 13 Jul 2016 03:05:33 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <113869054.55.1468379135409.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <223822942.52.1468367832938.JavaMail.jenkins@jenkins-9.freebsd.org> References: <223822942.52.1468367832938.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #3581 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 03:05:35 -0000 FreeBSD_HEAD_arm64 - Build #3581 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3581/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3581/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/3581/console Change summaries: 302690 by bdrewery: Revert r302670 and r302671 for now. MACHINE_CPUARCH smells like MACHINE except for arm64/aarch64 which has it backwards. From owner-freebsd-arm@freebsd.org Wed Jul 13 08:53:36 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D637B9707F for ; Wed, 13 Jul 2016 08:53:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 402D31D4B for ; Wed, 13 Jul 2016 08:53:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23129 invoked from network); 13 Jul 2016 08:54:08 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Jul 2016 08:54:08 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 13 Jul 2016 04:54:18 -0400 (EDT) Received: (qmail 15942 invoked from network); 13 Jul 2016 08:54:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jul 2016 08:54:18 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 3F1AA1C405F; Wed, 13 Jul 2016 01:53:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc has odd mix of signed wchar_t and unsigned char] From: Mark Millard In-Reply-To: Date: Wed, 13 Jul 2016 01:53:27 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, freebsd-arm , FreeBSD PowerPC ML , Bruce Evans , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> To: Andrey Chernov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 08:53:36 -0000 [The below does note that TARGET=3Dpowerpc has a mix of signed wchar_t = and unsigned char types and most architectures have both being signed = types.] On 2016-Jul-11, at 8:57 PM, Andrey Chernov wrote: > On 12.07.2016 5:44, Mark Millard wrote: >> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: >>=20 >> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of >> ___wchar_t (if that is distinct). >> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; = not >> necessarily a valid char value >> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; = not >> necessarily a valid char value >=20 > It seems you are right about "not a valid char value", I'll back this > change out. >=20 >> As far as I know arm FreeBSD uses unsigned character types (of = whatever >> width). >=20 > Probably it should be unsigned for other architectures too, clang does > not generate negative values with L'' literals and locale use = only > positive values too. Looking around: # grep -i wchar sys/*/include/_types.h sys/arm/include/_types.h:typedef unsigned int ___wchar_t; sys/arm/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ sys/arm/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ sys/arm64/include/_types.h:typedef unsigned int ___wchar_t; sys/arm64/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ sys/arm64/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ sys/mips/include/_types.h:typedef int ___wchar_t; sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ sys/powerpc/include/_types.h:typedef int ___wchar_t; sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ sys/riscv/include/_types.h:typedef int ___wchar_t; sys/riscv/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/riscv/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ sys/sparc64/include/_types.h:typedef int ___wchar_t; sys/sparc64/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/sparc64/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ sys/x86/include/_types.h:typedef int ___wchar_t; sys/x86/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/x86/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ So only arm and arm64 have unsigned wchar_t types. [NOTE: __CHAR16_TYPE__ and __CHAR32_TYPE__ are always unsigned: in C++11 = terms char16_t is like std::uint_least16_t and char32_t is like = std::uint_least32_t despite being distinct types. So __CHAR16_TYPE__ and = __CHAR32_TYPE__ are ignored below.] The clang 3.8.0 compiler output has an odd mix for TARGET_ARCH=3Dpowerpc = and TARGET_ARCH=3Dpowerpc64 . . . armv6 has unsigned types for both char and __WCHAR_TYPE__. aarch64 has unsigned types for both char and __WCHAR_TYPE__. powerpc has unsigned for char but signed for __WCHAR_TYPE__. powerpc64 has unsigned for char but signed for __WCHAR_TYPE__. amd64 has signed types for both char and __WCHAR_TYPE__. i386 has signed types for both char and __WCHAR_TYPE__. mips has signed types for both char and __WCHAR_TYPE__. sparc64 has signed types for both char and __WCHAR_TYPE__. (riscv is not covered by clang as I understand) The details via compiler #define's. . . # clang --target=3Darmv6-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ . . . #define __CHAR_BIT__ 8 #define __CHAR_UNSIGNED__ 1 . . . #define __WCHAR_MAX__ 4294967295U #define __WCHAR_TYPE__ unsigned int #define __WCHAR_UNSIGNED__ 1 #define __WCHAR_WIDTH__ 32 . . . # clang --target=3Daarch64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ . . . #define __CHAR_BIT__ 8 #define __CHAR_UNSIGNED__ 1 . . . #define __WCHAR_MAX__ 4294967295U #define __WCHAR_TYPE__ unsigned int #define __WCHAR_UNSIGNED__ 1 #define __WCHAR_WIDTH__ 32 . . . # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ . . . #define __CHAR_BIT__ 8 #define __CHAR_UNSIGNED__ 1 . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . Is powerpc wrong? # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more . . . #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ . . . #define __CHAR_BIT__ 8 #define __CHAR_UNSIGNED__ 1 . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . Is powerpc64 wrong? # clang --target=3Damd64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ . . . #define __CHAR_BIT__ 8 . . . (note the lack of __CHAR_UNSIGNED__) . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . # clang --target=3Di386-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ . . . #define __CHAR_BIT__ 8 . . . (note the lack of __CHAR_UNSIGNED__) . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . # clang --target=3Dmips-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ . . . #define __CHAR_BIT__ 8 . . . (note the lack of __CHAR_UNSIGNED__) . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . # clang --target=3Dsparc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ . . . #define __CHAR_BIT__ 8 . . . (note the lack of __CHAR_UNSIGNED__) . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Jul 13 11:55:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B4DEB97035 for ; Wed, 13 Jul 2016 11:55:51 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3F611C8 for ; Wed, 13 Jul 2016 11:55:51 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 234912AA4AB; Wed, 13 Jul 2016 05:55:04 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id E4E951CDE4; Wed, 13 Jul 2016 07:55:42 -0400 (EDT) Date: Wed, 13 Jul 2016 07:55:42 -0400 From: Diane Bruce To: Da Rock Cc: freebsd-arm@freebsd.org Subject: Re: [BUMP]: Re: Raspberry PI 3 - initial newb - help! Message-ID: <20160713115542.GB11970@night.db.net> References: <5781B068.1020107@herveybayaustralia.com.au> <5785A475.1070808@herveybayaustralia.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5785A475.1070808@herveybayaustralia.com.au> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 11:55:51 -0000 On Wed, Jul 13, 2016 at 12:16:21PM +1000, Da Rock wrote: > Still struggling a bit with u-boot concepts: rpi boots, looks in the mbr > with fat partition for u-boot. U-boot is not specifically in any address > as such so it has to actually look for it. So why does ubldr require a > start address? Which address is it looking for? And how do I find it? > Until I figure that out I can't compile it can I? > > To clarify also, the dtb is configured in the config for u-boot? Then > u-boot passes that in to ubldr? Or can't FBSD handle that at this stage? I'm working on a u-boot for RPi3. Give me a few more days. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arm@freebsd.org Wed Jul 13 17:55:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 330ECB98F91 for ; Wed, 13 Jul 2016 17:55:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22C671808 for ; Wed, 13 Jul 2016 17:55:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6DHtIXR010068 for ; Wed, 13 Jul 2016 17:55:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 211087] sys/arm/ti/cpsw/if_cpsw.c:1937: bad expression ? Date: Wed, 13 Jul 2016 17:55:18 +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 Some People X-Bugzilla-Who: dcb314@hotmail.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.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 17:55:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211087 Bug ID: 211087 Summary: sys/arm/ti/cpsw/if_cpsw.c:1937: bad expression ? Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: dcb314@hotmail.com sys/arm/ti/cpsw/if_cpsw.c:1937]: (style) Expression '(X & 0x8800) =3D=3D 0x= 4800' is always false. Source code is if ((flags & (CPDMA_BD_SOP | CPDMA_BD_TDOWNCMPLT)) =3D=3D (CPDMA_BD_EOP | CPDMA_BD_TDOWNCMPLT)) { Maybe better code if ((flags & (CPDMA_BD_SOP | CPDMA_BD_TDOWNCMPLT)) =3D=3D (CPDMA_BD_SOP | CPDMA_BD_TDOWNCMPLT)) { --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Jul 13 19:45:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04BB8B98B9F for ; Wed, 13 Jul 2016 19:45:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 A22251F2F for ; Wed, 13 Jul 2016 19:45:30 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 5B8B0220F06 for ; Wed, 13 Jul 2016 14:45:22 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> Date: Wed, 13 Jul 2016 14:45:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060708050807010708030600" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:45:31 -0000 This is a cryptographically signed message in MIME format. --------------ms060708050807010708030600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The latest conundrum..... I am attempting to "clone" a running SD card for the Pi2. I have re-created the SD filestructure using gpart using the following sequence, starting with a blank card (e.g. "da0") and aligning the Unix filestructure on a 4MB boundary (which is my usual practice for any sort of solid-state device) #!/bin/sh gpart create -s MBR $1 gpart add -t '!12' -s 50m $1 gpart set -a active -i 1 $1 gpart add -t freebsd -a 4m $1 newfs_msdos $1s1 gpart create -s bsd $1s2 gpart add -t freebsd-ufs $1s2 newfs -U -L rootfs $1s2a then mounted the two "working" partitions this generates (da0s1 and da0s2a) and successfully transferred the root and msdos filesystems using rsync. The result appears to be fine when examined side-by-side with the original, other than the fact that it looks like there were sparse files that have been expanded, but when you try to boot the result it starts, appears to mount the root filesystem, says it's not clean (which is odd since it certainly was dismounted cleanly with umount!), and the system hangs after displaying the UE (ethernet) hardware MAC address on an HDMI console. There is no response from a USB connected keyboard if you try to ^C out of wherever it is (although it DOES know it's there and displays the "found" message when you plug the keyboard in.) If you wait long enough it will tell you it has unblocked the random device. Unfortunately I have no idea where it's hanging in the startup beyond this and have no way to find out since I can get out of wherever it is, even with a physical keyboard plugged into it. Putting the original card back in and sticking the one that failed to boot in an SD card reader produces the following. Base partition structure of the working sd card: # gpart show /dev/mmcsd0 =3D> 63 62552001 mmcsd0 MBR (30G) 63 102375 1 !12 [active] (50M) 102438 62443482 2 freebsd (30G) 62545920 6144 - free - (3.0M) Of the other card: # gpart show /dev/da0 =3D> 63 62552001 da0 MBR (30G) 63 102400 1 !12 [active] (50M) 102463 4033 - free - (2.0M) 106496 62439424 2 freebsd (30G) 62545920 6144 - free - (3.0M) # ls -al /dev/mm* crw-r----- 1 root operator 0x4e Jul 10 19:24 /dev/mmcsd0 crw-r----- 1 root operator 0x4f Jul 10 19:24 /dev/mmcsd0s1 crw-r----- 1 root operator 0x50 Jul 10 19:24 /dev/mmcsd0s2 crw-r----- 1 root operator 0x53 Jul 10 19:24 /dev/mmcsd0s2a And of the one that will not come up but does boot, in a SD card reader: # ls -al /dev/da0* crw-r----- 1 root operator 0x56 Jul 13 19:27 /dev/da0 crw-r----- 1 root operator 0x58 Jul 13 19:27 /dev/da0s1 crw-r----- 1 root operator 0x5d Jul 13 19:27 /dev/da0s2 crw-r----- 1 root operator 0x60 Jul 13 19:27 /dev/da0s2a # mount -t msdosfs /dev/da0s1 /mnt # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ufs/rootfs 30229724 824548 26986800 3% / devfs 1 1 0 100% /dev /dev/msdosfs/MSDOSBOOT 51128 7560 43568 15% /boot/msdos tmpfs 51200 4 51196 0% /tmp /dev/da0s1 51128 7560 43568 15% /mnt # ls /mnt BOOTCODE.BIN START_CD.ELF CONFIG.TXT START_X.ELF FIXUP.DAT System Volume Information FIXUP_CD.DAT U-BOOT.BIN FIXUP_X.DAT UBLDR RPI2.DTB UBLDR.BIN START.ELF Now here's the thing -- the unix-side filesystem has to be good too, because the kernel is not in the MSDOS partition, it's in /boot/kernel on the Unix side and it both loads and starts! But just for good measure, here's what we got in there: # mount -o ro /dev/da0s2a /mnt # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ufs/rootfs 30229724 824548 26986800 3% / devfs 1 1 0 100% /dev /dev/msdosfs/MSDOSBOOT 51128 7560 43568 15% /boot/msdos tmpfs 51200 4 51196 0% /tmp /dev/da0s2a 30233340 2299932 25514744 8% /mnt I can mount it, and everything is there. Specifically, if I look through /etc/rc.d and the /etc/rc file itself, both are present, as is /sbin/init and the checksums match too. With both filesystems mounted (the sd card cloned to on /mnt) tunefs says they both have the label set correctly and all the flags are the same -- the only difference is the space to hold for metadata blocks, which is likely because the original load was done with an image and then growfs resized it. # tunefs -p /mnt tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) rootfs # tunefs -p / tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 2488 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) rootfs I've never had trouble cloning a disk like this in the Intel world and quite-clearly the system CAN find the cloned card's filesystem structure or the kernel would not come up -- but it does.... What the hell am I doing wrong? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060708050807010708030600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTMxOTQ1MjFaME8GCSqGSIb3DQEJBDFCBEAA vsRL/odPvGZMGSY1jwP6gPynou1A/l0V11PGziDuxqv/oRsSJe6zjrDqft+M2+UxqD6l+2f7 lI+BZutDfH1YMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIANCyqPSjm wXa4ca2DcWA4tz4zPpBpge7ZlQZ4aMMqqQL+oAH5T7Xoc8bS56ogAxNw20lU6iKR9/s/ysn+ r5p1VMhvabrjkG3kQJu6pFMC/hDyAVDyIVGuclKJGlyY6by5lm1CLvK1PDt9bWn0TDkwVo+I HMiMxprF5ADJXt1D5WASqp3X9y1lJKQE3AkSRbErg+RWiIdZ5RJd/yTMafDh9AbZeR0b+rsh R5ywkwg3BpgmE1r6H0vTS4mC2G+Us+5iaSnCLKGRHqSD1IUDj4utGKllcp+fyKj4/PZUpC0u 2MGvkmTm1YLEDwQJmN2i8QzqqQAjG4GHjaEUyUiHVMlaDiXfsLKHnak3OWUxIhlfm8HaOA3Q wqXigHPMWBY408bBB/QYYq9Vp9EG4Q18v1ghg9hjQv49aX0v6CMRmyKoHnhdY6LS3l9XquSo TjkFBL3b8XyqKnVNxbVajcSAQni4QCYm8jgl+eHVlmRRsKZLgEjwX32IYrKhK/lrHrb8KTfV F3lWI1UIPaPjVmrYZbmJQyJQY/7C392TizMvPAWgKFIdRAfLO96OP8dNaLWe8+l8VZxrohrm HPL5/RDQwKLLosEHUERSmgJ1b5vwTIb7tLxUwqtyPbFGANuABM8CTouRLqH0wh9HDwdz6Ukm nOkNUmY4NLBDPsDq5/9eqtZfIZ0AAAAAAAA= --------------ms060708050807010708030600-- From owner-freebsd-arm@freebsd.org Wed Jul 13 19:54:15 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76F3EB98DFE for ; Wed, 13 Jul 2016 19:54:15 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 236871612 for ; Wed, 13 Jul 2016 19:54:14 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 9DCE6220FA3 for ; Wed, 13 Jul 2016 14:54:13 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm@freebsd.org References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> From: Karl Denninger Message-ID: Date: Wed, 13 Jul 2016 14:54:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090105020105080907090509" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:54:15 -0000 This is a cryptographically signed message in MIME format. --------------ms090105020105080907090509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Oh, there is one difference: tunefs -p on the new device *works* (no idea why however since there's no slice there) where it FAILS on the original: root@Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2 tunefs: /dev/mmcsd0s2: could not read superblock to fill out disk root@Test-MCP:/home/karl # tunefs -p /dev/da0s2 tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) rootfs Huh? On 7/13/2016 14:45, Karl Denninger wrote: > The latest conundrum..... > > I am attempting to "clone" a running SD card for the Pi2. > > I have re-created the SD filestructure using gpart using the following > sequence, starting with a blank card (e.g. "da0") and aligning the Unix= > filestructure on a 4MB boundary (which is my usual practice for any sor= t > of solid-state device) > > #!/bin/sh > > gpart create -s MBR $1 > gpart add -t '!12' -s 50m $1 > gpart set -a active -i 1 $1 > gpart add -t freebsd -a 4m $1 > newfs_msdos $1s1 > gpart create -s bsd $1s2 > gpart add -t freebsd-ufs $1s2 > newfs -U -L rootfs $1s2a > > then mounted the two "working" partitions this generates (da0s1 and > da0s2a) and successfully transferred the root and msdos filesystems > using rsync. The result appears to be fine when examined side-by-side > with the original, other than the fact that it looks like there were > sparse files that have been expanded, but when you try to boot the > result it starts, appears to mount the root filesystem, says it's not > clean (which is odd since it certainly was dismounted cleanly with > umount!), and the system hangs after displaying the UE (ethernet) > hardware MAC address on an HDMI console. There is no response from a > USB connected keyboard if you try to ^C out of wherever it is (although= > it DOES know it's there and displays the "found" message when you plug > the keyboard in.) > > If you wait long enough it will tell you it has unblocked the random > device. Unfortunately I have no idea where it's hanging in the startup= > beyond this and have no way to find out since I can get out of wherever= > it is, even with a physical keyboard plugged into it. > > Putting the original card back in and sticking the one that failed to > boot in an SD card reader produces the following. > > Base partition structure of the working sd card: > > # gpart show /dev/mmcsd0 > =3D> 63 62552001 mmcsd0 MBR (30G) > 63 102375 1 !12 [active] (50M) > 102438 62443482 2 freebsd (30G) > 62545920 6144 - free - (3.0M) > > Of the other card: > # gpart show /dev/da0 > =3D> 63 62552001 da0 MBR (30G) > 63 102400 1 !12 [active] (50M) > 102463 4033 - free - (2.0M) > 106496 62439424 2 freebsd (30G) > 62545920 6144 - free - (3.0M) > > > # ls -al /dev/mm* > crw-r----- 1 root operator 0x4e Jul 10 19:24 /dev/mmcsd0 > crw-r----- 1 root operator 0x4f Jul 10 19:24 /dev/mmcsd0s1 > crw-r----- 1 root operator 0x50 Jul 10 19:24 /dev/mmcsd0s2 > crw-r----- 1 root operator 0x53 Jul 10 19:24 /dev/mmcsd0s2a > > And of the one that will not come up but does boot, in a SD card reader= : > > # ls -al /dev/da0* > crw-r----- 1 root operator 0x56 Jul 13 19:27 /dev/da0 > crw-r----- 1 root operator 0x58 Jul 13 19:27 /dev/da0s1 > crw-r----- 1 root operator 0x5d Jul 13 19:27 /dev/da0s2 > crw-r----- 1 root operator 0x60 Jul 13 19:27 /dev/da0s2a > > # mount -t msdosfs /dev/da0s1 /mnt > # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ufs/rootfs 30229724 824548 26986800 3% / > devfs 1 1 0 100% /dev > /dev/msdosfs/MSDOSBOOT 51128 7560 43568 15% /boot/msdos > tmpfs 51200 4 51196 0% /tmp > /dev/da0s1 51128 7560 43568 15% /mnt > > # ls /mnt > BOOTCODE.BIN START_CD.ELF > CONFIG.TXT START_X.ELF > FIXUP.DAT System Volume Information > FIXUP_CD.DAT U-BOOT.BIN > FIXUP_X.DAT UBLDR > RPI2.DTB UBLDR.BIN > START.ELF > > Now here's the thing -- the unix-side filesystem has to be good too, > because the kernel is not in the MSDOS partition, it's in /boot/kernel > on the Unix side and it both loads and starts! But just for good > measure, here's what we got in there: > > # mount -o ro /dev/da0s2a /mnt > # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ufs/rootfs 30229724 824548 26986800 3% / > devfs 1 1 0 100% /dev > /dev/msdosfs/MSDOSBOOT 51128 7560 43568 15% /boot/msdos= > tmpfs 51200 4 51196 0% /tmp > /dev/da0s2a 30233340 2299932 25514744 8% /mnt > > I can mount it, and everything is there. Specifically, if I look > through /etc/rc.d and the /etc/rc file itself, both are present, as is > /sbin/init and the checksums match too. > > With both filesystems mounted (the sd card cloned to on /mnt) tunefs > says they both have the label set correctly and all the flags are the > same -- the only difference is the space to hold for metadata blocks, > which is likely because the original load was done with an image and > then growfs resized it. > > # tunefs -p /mnt > tunefs: POSIX.1e ACLs: (-a) disabled > tunefs: NFSv4 ACLs: (-N) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) enabled > tunefs: soft update journaling: (-j) disabled > tunefs: gjournal: (-J) disabled > tunefs: trim: (-t) disabled > tunefs: maximum blocks per file in a cylinder group: (-e) 4096 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: space to hold for metadata blocks: (-k) 6408 > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L) rootfs > > # tunefs -p / > tunefs: POSIX.1e ACLs: (-a) disabled > tunefs: NFSv4 ACLs: (-N) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) enabled > tunefs: soft update journaling: (-j) disabled > tunefs: gjournal: (-J) disabled > tunefs: trim: (-t) disabled > tunefs: maximum blocks per file in a cylinder group: (-e) 4096 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: space to hold for metadata blocks: (-k) 2488 > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L) rootfs > > I've never had trouble cloning a disk like this in the Intel world and > quite-clearly the system CAN find the cloned card's filesystem structur= e > or the kernel would not come up -- but it does.... > > What the hell am I doing wrong? > --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090105020105080907090509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTMxOTU0MTJaME8GCSqGSIb3DQEJBDFCBED1 owVoZRaEDhENLJHrgxuw71er/79/QX8cypBTvfSYyug7u7eF4LMLCfnpLVJsF2lYIk1ytzUh h6C+zPTXvU0LMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAqBIsmIJJ HwcLjeisxqV7O5FJEzvQy/8WEgQcCJnl8sUeAZCGK1nLEUrk1lL3yxqbhRY8/o3+oCGFyFNi fxuVi1fYuOwjFe/KuZZaq6U9wlMYfnCZAru/+pThiogyekdHMtrXJp/MNspdOxdCvKwUMlTN yhV4viMX4GIO3K7uvXeWE99UX4KL4VrajNrHtizlERqexkSLwmjB8lSTa4nhCMoGf4r2Ugal ZFMkRKEZXVcSFsQw3+8AhroqIQvj8Wo712A5rXBUbo5Tjw2uSgX/j9yDUjCg3epbqDR9bcnw tD6VXwC+YH75fgBdmAZnGvx4/mgc+Q/U9JePm5mwqAingmeD7ocioEt9M+EDK3e0WoEDJPkp ozBuzShkqeKgjTq1Dx8fphvlgPIKoj4UMDO8dulC2sQkDrNePviQUkLX4iIgov3hdsTqe/hd R5hAlhFoix6opH3KxTtk95n+aUKVoKleYLfEAG+F+J22e9zE8rMgXrcFmGNf0mVur4zh2dVJ tf4QY3KFA14d4Qr3591F9xiIzTxWR9WPK0wuKC7tpyPU1P2pYq2TCsiQ3ftuGc/Bom5sTE2c PjsIk10+/4ocsaMNY8xsh/t/FgkS1V3dm36BI5s5+FnnTktUYaOR3XJ0VZj5G93Rgap+FI9c Gjd2MsLT74rvrO1LgQMh7/kKqAcAAAAAAAA= --------------ms090105020105080907090509-- From owner-freebsd-arm@freebsd.org Wed Jul 13 21:23:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 173D3B97BF4 for ; Wed, 13 Jul 2016 21:23:38 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (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 C4D381468 for ; Wed, 13 Jul 2016 21:23:37 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1468445010; bh=j4OY6CpacqVfbl64dWNNEDW/19mYYM7wbr/GS8p/ifg=; h=From:Subject:Date:References:To:From:Subject; b=K8rRkLKotpIh7y05knFvWmdxoKDBJxhAqREZpmVL+zsr2vDg6xsAfxc3tXyC7y4lLmlw3nQaqQdTCCMQMDzJRytH77cItZBlsYEL92O+u3P64fCPY9U94hspdIgeTIV3qqduhrFwLJTi+0PxGHUeiV9eV8j0NA4Sff1mY2iMtRpl7JeLJr4kz64ghyPR/qg7QY6egQmtkzgC2YCKhNhF9ZUEicBfRmxLSoGzRTSgqjGXI1XgYGDsVTIre2qvPLZhCuOOXIbnucxSFCMWoKDVAhr/H3VQugg3OyN64A+fTmgNTCrnSFHQVeay5q1AYtOJ43gH9+y03HU+sllYUorpCA== Received: from [98.139.170.178] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jul 2016 21:23:30 -0000 Received: from [98.139.213.10] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jul 2016 21:23:30 -0000 Received: from [127.0.0.1] by smtp110.mail.bf1.yahoo.com with NNFMP; 13 Jul 2016 21:23:30 -0000 X-Yahoo-Newman-Id: 249882.4389.bm@smtp110.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mtChb0sVM1kREfyRLBcohYCexWTKWTSVjPyBQsk43QuzzXi hyDhMjGIkQlCDifF0jmxF6Kur7rFQ2SKgZBxAOX4IfTJ9FsoRNmUT9litcfN AeT07GDqROAz07Ro4gOZHoye7ljmkQUaOXxqLhqJ00hll8t2BPB3u0K3138h J16DDpi2RkMAL_Aw23cGJzNLzcbzKQjaE334CbCM2LjrBeZM.ZKjouuZmt.2 jVoVLfRNoHycETbW63YmFp5F6RLYsgThF1LGe2nuD0_QGURPpxmJby8n.h1o _9Pm7F_xEwKSBki3WRAlezme8Edg9s_4FVBc72Ew1wb269kmkogKH_RdJEot EFt7992G.kAlI5yVVxMSUAI4AYAVkfEYTb31XCl8S6lkZQ1vZmJmtbAqR_L8 FhJaKMASl5GQGClAfJOJjMCN9Zg9ng9JV0KpzW1ePzrQM_pBckQo_1EFnw0w hHI2cD_ps.trBok04BqYP08t11xnjoK58fwGPCcJzxYRYfAduBqwsopT5sdb IhF_yvGJq64rgl02S2jx7UMRrKEoSJqk3eOIuES2aTvK2LkBa5qfvmA6zFAx mbRlDqewISWHagPNU5ka4rfMDU1xfPceZHbiRzQ-- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD on Snickerdoodle Date: Wed, 13 Jul 2016 14:23:28 -0700 References: <2A4E46AD-6574-4D4E-9759-D3C53C8B6F5B.ref@yahoo.com> To: freebsd-arm@freebsd.org Message-Id: <89DCB6E3-B80D-4CBE-A493-6B7A484B8BB5@yahoo.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 21:23:38 -0000 Hello: I have booted FreeBSD on a Snickerdoodle, a low-cost ($65) Xilinx Zynq = board. I=E2=80=99m glad to see Zynq boards are finally coming down in = price. The =E2=80=9Cgigglebits=E2=80=9D five-port GigE baseboard also = looks interesting (see in the crowdsupply link). https://www.crowdsupply.com/krtkl/snickerdoodle http://krtkl.com/ http://www.skibo.net/zedbsd/#snickerdoodle I received an early release of the board late last week (one of the = founders of krtkl is a FreeBSD fan and contacted me). I had FreeBSD up = and running fairly quickly by simply tweaking their port of u-boot. = But, unfortunately, it has its WiFi module on SDIO like the RPi3 so I = think it=E2=80=99ll be a while before that works. =E2=80=94Thomas =E2=80=94=E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Wed Jul 13 21:36:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03382B97EB1 for ; Wed, 13 Jul 2016 21:36:14 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.metanet.ch", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C05B91AF7 for ; Wed, 13 Jul 2016 21:36:12 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from qubik.local (cpe-76-173-9-214.hawaii.res.rr.com [76.173.9.214]) by newton.metanet.ch (Postfix) with ESMTPSA id ECDB13380F9E for ; Wed, 13 Jul 2016 23:26:55 +0200 (CEST) Reply-To: werner@thieprojects.ch Subject: Re: FreeBSD on Snickerdoodle References: <2A4E46AD-6574-4D4E-9759-D3C53C8B6F5B.ref@yahoo.com> <89DCB6E3-B80D-4CBE-A493-6B7A484B8BB5@yahoo.com> To: freebsd-arm@freebsd.org From: Werner Thie Organization: Thie & Co Projects Message-ID: <55a37c8e-3713-df82-e1bb-9c83e843643c@thieprojects.ch> Date: Wed, 13 Jul 2016 11:27:23 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <89DCB6E3-B80D-4CBE-A493-6B7A484B8BB5@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 21:36:14 -0000 Hello Thomas sounds great, are you able to poke the FPGA? Werner On 7/13/16 11:23 AM, Thomas Skibo via freebsd-arm wrote: > Hello: > > I have booted FreeBSD on a Snickerdoodle, a low-cost ($65) Xilinx Zynq board. I’m glad to see Zynq boards are finally coming down in price. The “gigglebits” five-port GigE baseboard also looks interesting (see in the crowdsupply link). > > https://www.crowdsupply.com/krtkl/snickerdoodle > http://krtkl.com/ > > http://www.skibo.net/zedbsd/#snickerdoodle > > I received an early release of the board late last week (one of the founders of krtkl is a FreeBSD fan and contacted me). I had FreeBSD up and running fairly quickly by simply tweaking their port of u-boot. But, unfortunately, it has its WiFi module on SDIO like the RPi3 so I think it’ll be a while before that works. > > —Thomas > > —— > Thomas Skibo > thomasskibo@yahoo.com > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Wed Jul 13 22:37:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6143B98DC4 for ; Wed, 13 Jul 2016 22:37:39 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (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 7F83A1A71 for ; Wed, 13 Jul 2016 22:37:39 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1468449457; bh=TofvDL6vPbsVNq+LAlCOhb11pdonI/AIgY+OkSXZArQ=; h=From:Subject:Date:To:From:Subject; b=PUfMYOcfIY83YRZUI/6ZCTfQwi4nftWLddYad51y6NBQZF0kuU3WTq5pqXRK2ErqCtM1EPfy1bFbNAjAXxPLerxh76nFl5Hw4lhWcGzryawQd1AK5v0SBhDU6AXx2o3H5b90KLbWkTklxTV59SB0hvEQOtvLHP4Xr2b37/XEf7HOHDVZMbMwsJ1ZuSo9/bn54puD2HpKnTr5uMh0xqz12qRx8TR10s8YI9dR94DNxd6cObOuLkNyiVNHBMpGTNnTcYZyuMvGArB7NK/dvXTba/2Y56ythGOF0Kdh7elglUJpqhiguW3jdt1AX2eJgK5pNkYWiKztxDiLbQSQLXGd6w== Received: from [66.196.81.170] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jul 2016 22:37:37 -0000 Received: from [98.139.211.200] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jul 2016 22:37:37 -0000 Received: from [127.0.0.1] by smtp209.mail.bf1.yahoo.com with NNFMP; 13 Jul 2016 22:37:37 -0000 X-Yahoo-Newman-Id: 868020.6769.bm@smtp209.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: t9zfx18VM1n5MB.1RCCew4y54oOhJLm2AeA3U7r4CBVEenU Gaih5_2QGiRJetzGbmfQuDSlQCpOqWS4kyeHKf2ZkgLGqKrkaOamopPjoxfB 4hHpjRSjSKIzPq0QRTGFhnEUdqhufYZqv5n3SyIIl9LtwGxelvqK2MSgXnNW CCTE.Dtbo4Pe1sO0I6IkgPNQEG9cje6LsQnQu1bQgGG1UbDXmzjGnElcElt0 WWJgZlj9rStG_9hBRd7YIIghSRMb6EisKQNsW0_xpdWD6shR4XIPvczVyPGc XwVlNY5qZcJTritOJVyAAUK2CUrsdedPtpC5gsAavn8l6KAGDhNbZbCINFe3 f0RPyR.oyhftzeShdcOtE.uIDO4BO_bDP62Od3Z2uLn96l4PnlbcUAfR2MKe MFWzzrczmZ5Wg.qcoap18A7WtVXHJeXy5cjEBizhEMyNC7.OLQtdcA2B3fB8 bE32gKFY5ta7ajDVHbnGwecMnTj3HoL7HdRFP27tVqEjQTE7MgvqfT3Uzrvi TiXLLgBauMG4VnX9f7XabRhQ82IjrijRfDJ1o_bUiUHPTBh9xT.ZlKeZx.Lm 6ZHrZJ98WLQ-- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD on Snickerdoodle Message-Id: <2EA4652E-153C-41E1-A31B-EB2E87C14848@yahoo.com> Date: Wed, 13 Jul 2016 15:37:35 -0700 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 22:37:39 -0000 > Hello Thomas >=20 > sounds great, are you able to poke the FPGA? >=20 > Werner There is a device driver for programming the FPGA. It allows you to = program the FPGA with a bitstream. See devcfg(4). =E2=80=94=E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Thu Jul 14 00:08:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A54BB9870C for ; Thu, 14 Jul 2016 00:08:56 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AD7E1EB0 for ; Thu, 14 Jul 2016 00:08:56 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 9CD4AA18; Wed, 13 Jul 2016 20:08:48 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11-Alpha to 11-Beta rewrite card or buildworld From: Paul Mather In-Reply-To: Date: Wed, 13 Jul 2016 20:08:47 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0BDFDAC6-CC11-4812-B007-7B01F5011637@gromit.dlib.vt.edu> References: <4876c9e05d5.30c7197a@mail.schwarzes.net> <20160711050802.4743251.48194.8248@gmail.com> <271F1F0A-B8B5-4A13-8BB8-3C5323622CDD@gromit.dlib.vt.edu> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 00:08:56 -0000 On Jul 11, 2016, at 10:00 AM, Karl Denninger wrote: > On 7/11/2016 08:54, Paul Mather wrote: >> On Jul 11, 2016, at 9:24 AM, Karl Denninger = wrote: >>=20 >>> On 7/11/2016 07:51, Paul Mather wrote: >>>> On Jul 11, 2016, at 1:08 AM, Russell Haley = wrote: >>>>=20 >>>>> Sorry about the top post.=20 >>>>>=20 >>>>> If your not trying to learn about the build process and=E2=80=8E = you don't have a custom build requirement, why not use a prebuilt image = move on to validating the running OS instead of repeating what the build = server does? >>>>>=20 >>>>> I would think there is more value in finding anomalies in your = favorite applications. =46rom my understanding there have been big = changes to the fundamentals of the OS (i.e hard float, compiler = upgrades, byte alignments etc). >>>> Speaking for myself, I just find the build{world,kernel} + = install{kernel,world} + mergemaster sequence of updating the system a = much more ingrained and normal method of doing things. It seems = "natural" to me to update my FreeBSD/arm systems the same way I update = my FreeBSD/amd64 systems. >>>>=20 >>>> Besides, if I overwrote my SD card with a new install image, I'd = lose all my settings (e.g., users, custom /usr/local/etc/pkg/repos/ = repository, swap partition on SD card, /etc/fstab changes to make /tmp = bigger[*], etc.). It's more natural for me to use the standard update = technique than redo those changes from scratch each time I update the = OS. (I'm using SaltStack to configure more and more, but even getting a = minion set up means it's easier to update the standard way than start = with a fresh install image and have to re-bootstrap SaltStack.) >>>>=20 >>>> Cheers, >>>>=20 >>>> Paul. >>>>=20 >>> The reason I do the "crossbuild" + "rsync" thing is that it gives me = the >>> ability to do the buildworld/buildkernel/installworld/installkernel >>> paradigm to a "holding directory" on a very fast machine, then rsync = the >>> results. (Mounting the holding directory via NFS works as well but = I >>> see no real advantage to that over using rsync) >>>=20 >>> That means I don't lose anything I did to the machine after install >>> (e.g. users, etc) and in addition I can put local patches on the = source >>> tree if required, but I still get a reasonable build time. >> I've successfully done cross building on a fast FreeBSD/amd64 machine = but have always had to move the SD card physically to that machine to do = the install{kernel,world} + mergemaster phase. The reason for this is = when I tried rsyncing to copy to the FreeBSD/arm system the rsync = application would not handle file flags (noschg, etc.) properly and = rsyncing would fail, even though I'd built it with the file flags patch = enabled. Going by what you say above, that appears to work properly = now, so I may re-try that. >>=20 >> I've also not had luck cross building on a fast FreeBSD/amd64 system = and then trying to install on FreeBSD/arm by NFS mounting the src and = obj crossbuild directories and doing an install{kernel,world} + = mergemaster on the FreeBSD/arm system. When I posted about this I = believe the reason is that the build systems gets confused about the = change in build and install paths. There may also be something about = the build/install toolchain, too. I forget. I just remember it didn't = seem to work for me when I tried it and asked about it on this mailing = list. :-) >>=20 >> If someone were to do a little "fastest way to update your = FreeBSD/arm OS without having to move the SD card physically to the = build system" HOWTO, that would be great. ;-) >>=20 >> Cheers, >>=20 >> Paul. > You do need to tell rsync to handle the schg flags -- for example: >=20 > rsync -av --force-schange --fileflags -I -e 'ssh -p > ' 'karl@newfs:/pics/CrossBuild/nfsroot/' / One problem I noticed with the above rsync command when I used it was it = only uses "-a". That option is a synonym for "-rlptgoD". As the man = page for rsync states: "(no -H,-A,-X)". Without an explicit "-H" hard links are not preserved. I learned this = first-hand when my /rescue directory lost all the hard linked files and = ballooned up in size. :-) I don't know whether rsync preserves sparse files. You should probably = also use --numeric-ids if your uid/gids are not synced up. AFAIK, the *surest* way to copy one UFS file system's contents to = another is to use dump and restore. Alas, if you're copying from ZFS to = UFS, I'm not sure what the safest method is: tar? Cheers, Paul. PS: Maybe another way would be to use mtree to preserve file attributes = and ownership between the source and the copy?= From owner-freebsd-arm@freebsd.org Thu Jul 14 00:14:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 740E7B98881 for ; Thu, 14 Jul 2016 00:14:01 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5128312DE for ; Thu, 14 Jul 2016 00:14:01 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 29970A1C; Wed, 13 Jul 2016 20:14:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Paul Mather In-Reply-To: Date: Wed, 13 Jul 2016 20:13:59 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 00:14:01 -0000 > On Jul 13, 2016, at 3:54 PM, Karl Denninger = wrote: >=20 > Oh, there is one difference: >=20 > tunefs -p on the new device *works* (no idea why however since there's > no slice there) where it FAILS on the original: >=20 > root@Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2 Shouldn't this be /dev/mmcsd0s2a? You're referencing the entire BSD = slice in the above command, not the UFS partition upon which the rootfs = lives. > tunefs: /dev/mmcsd0s2: could not read superblock to fill out disk >=20 > root@Test-MCP:/home/karl # tunefs -p /dev/da0s2 > tunefs: POSIX.1e ACLs: (-a) disabled > tunefs: NFSv4 ACLs: (-N) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) enabled > tunefs: soft update journaling: (-j) disabled > tunefs: gjournal: (-J) disabled > tunefs: trim: (-t) disabled > tunefs: maximum blocks per file in a cylinder group: (-e) 4096 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: space to hold for metadata blocks: (-k) 6408 > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L) rootfs Cheers, Paul.= From owner-freebsd-arm@freebsd.org Thu Jul 14 01:00:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E1D1B97654 for ; Thu, 14 Jul 2016 01:00:34 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (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 EC7F213C6 for ; Thu, 14 Jul 2016 01:00:33 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f41.google.com with SMTP id q132so51129348lfe.3 for ; Wed, 13 Jul 2016 18:00:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GaZX3Zul7amFxu9OXBSO+o+VbSL2HHuNJ57ZuUh8dXA=; b=VqDReiCIUJkbGvC/Hqe/3WTZLvekdO8wbTFjA8R/PssMf3AQFK5QOmdJGSKFDx77kZ qabxCWbQ+3taYNhuOZiNGanj/rWyHR5MPdERMMtYSF8bBwj72eawRkvgApZD15yvZpWY dVkYLYoj9jzbzbAR0MACP0xO3ONMSlOxmZ1cOfFmwQ+V4o7hYkOVWyZ5oaA5ETe5qG1G QDBmpxcuW1sFDSWc4mM6OqstncRJQaSjFY7Hlwo779KIeMvzHlm74ZJhPWdb1RHSIwsd EDiWU3ySKENEAWf1L1dLmJi/i6oQVMEIqRlmC8MryGYX573JoXg4WPNZlPuZdefcUp2v SSuw== X-Gm-Message-State: ALyK8tLmWc7B01tyffiqjqkcwgqXs8npYvRb+vuZKBHh7yDiQHj23LP0OdRyqiH38MddMQ== X-Received: by 10.25.154.136 with SMTP id c130mr5564967lfe.87.1468458026291; Wed, 13 Jul 2016 18:00:26 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id o10sm2456631lfo.47.2016.07.13.18.00.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 18:00:25 -0700 (PDT) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc has odd mix of signed wchar_t and unsigned char] To: Mark Millard References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> Cc: svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, freebsd-arm , FreeBSD PowerPC ML , Bruce Evans , FreeBSD Toolchain From: Andrey Chernov Message-ID: Date: Thu, 14 Jul 2016 04:00:24 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 01:00:34 -0000 On 13.07.2016 11:53, Mark Millard wrote: > [The below does note that TARGET=powerpc has a mix of signed wchar_t and unsigned char types and most architectures have both being signed types.] POSIX says nothing about wchar_t and char should be the same (un)signed. It is arm ABI docs may say so only. They are different entities differently encoded and cross assigning between wchar_t and char is not recommended. > > On 2016-Jul-11, at 8:57 PM, Andrey Chernov wrote: > >> On 12.07.2016 5:44, Mark Millard wrote: >>> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: >>> >>> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of >>> ___wchar_t (if that is distinct). >>> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not >>> necessarily a valid char value >>> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; not >>> necessarily a valid char value >> >> It seems you are right about "not a valid char value", I'll back this >> change out. >> >>> As far as I know arm FreeBSD uses unsigned character types (of whatever >>> width). >> >> Probably it should be unsigned for other architectures too, clang does >> not generate negative values with L'' literals and locale use only >> positive values too. > > Looking around: > > # grep -i wchar sys/*/include/_types.h > sys/arm/include/_types.h:typedef unsigned int ___wchar_t; > sys/arm/include/_types.h:#define __WCHAR_MIN 0 /* min value for a wchar_t */ > sys/arm/include/_types.h:#define __WCHAR_MAX __UINT_MAX /* max value for a wchar_t */ > sys/arm64/include/_types.h:typedef unsigned int ___wchar_t; > sys/arm64/include/_types.h:#define __WCHAR_MIN 0 /* min value for a wchar_t */ > sys/arm64/include/_types.h:#define __WCHAR_MAX __UINT_MAX /* max value for a wchar_t */ > sys/mips/include/_types.h:typedef int ___wchar_t; > sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > sys/powerpc/include/_types.h:typedef int ___wchar_t; > sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > sys/riscv/include/_types.h:typedef int ___wchar_t; > sys/riscv/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/riscv/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > sys/sparc64/include/_types.h:typedef int ___wchar_t; > sys/sparc64/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/sparc64/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > sys/x86/include/_types.h:typedef int ___wchar_t; > sys/x86/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/x86/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > > So only arm and arm64 have unsigned wchar_t types. > > [NOTE: __CHAR16_TYPE__ and __CHAR32_TYPE__ are always unsigned: in C++11 terms char16_t is like std::uint_least16_t and char32_t is like std::uint_least32_t despite being distinct types. So __CHAR16_TYPE__ and __CHAR32_TYPE__ are ignored below.] > > The clang 3.8.0 compiler output has an odd mix for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 . . . > > armv6 has unsigned types for both char and __WCHAR_TYPE__. > aarch64 has unsigned types for both char and __WCHAR_TYPE__. > powerpc has unsigned for char but signed for __WCHAR_TYPE__. > powerpc64 has unsigned for char but signed for __WCHAR_TYPE__. > amd64 has signed types for both char and __WCHAR_TYPE__. > i386 has signed types for both char and __WCHAR_TYPE__. > mips has signed types for both char and __WCHAR_TYPE__. > sparc64 has signed types for both char and __WCHAR_TYPE__. > (riscv is not covered by clang as I understand) > > The details via compiler #define's. . . > > # clang --target=armv6-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 4294967295U > #define __WCHAR_TYPE__ unsigned int > #define __WCHAR_UNSIGNED__ 1 > #define __WCHAR_WIDTH__ 32 > . . . > > # clang --target=aarch64-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 4294967295U > #define __WCHAR_TYPE__ unsigned int > #define __WCHAR_UNSIGNED__ 1 > #define __WCHAR_WIDTH__ 32 > . . . > > # clang --target=powerpc-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > Is powerpc wrong? > > # clang --target=powerpc64-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > Is powerpc64 wrong? > > > # clang --target=amd64-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . > > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > # clang --target=i386-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . > > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > > # clang --target=mips-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . > > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > # clang --target=sparc64-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . > > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > > > === > Mark Millard > markmi at dsl-only.net > From owner-freebsd-arm@freebsd.org Thu Jul 14 02:44:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2668B985E3 for ; Thu, 14 Jul 2016 02:44:22 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 869F7150A for ; Thu, 14 Jul 2016 02:44:22 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 5A2D622028B for ; Wed, 13 Jul 2016 21:44:19 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> To: freebsd-arm@freebsd.org From: Karl Denninger Message-ID: <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> Date: Wed, 13 Jul 2016 21:44:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040105040309050805020600" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 02:44:22 -0000 This is a cryptographically signed message in MIME format. --------------ms040105040309050805020600 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/13/2016 19:13, Paul Mather wrote: >> On Jul 13, 2016, at 3:54 PM, Karl Denninger wrote= : >> >> Oh, there is one difference: >> >> tunefs -p on the new device *works* (no idea why however since there's= >> no slice there) where it FAILS on the original: >> >> root@Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2 > > Shouldn't this be /dev/mmcsd0s2a? You're referencing the entire BSD sl= ice in the above command, not the UFS partition upon which the rootfs liv= es. Right. Here's the issue; it doesn't work on the original disk (as it shouldn't) on the entire BSD slice but... >> tunefs: /dev/mmcsd0s2: could not read superblock to fill out disk >> >> root@Test-MCP:/home/karl # tunefs -p /dev/da0s2 >> tunefs: POSIX.1e ACLs: (-a) disabled >> tunefs: NFSv4 ACLs: (-N) disabled >> tunefs: MAC multilabel: (-l) disabled >> tunefs: soft updates: (-n) enabled >> tunefs: soft update journaling: (-j) disabled >> tunefs: gjournal: (-J) disabled >> tunefs: trim: (-t) disabled >> tunefs: maximum blocks per file in a cylinder group: (-e) 4096 >> tunefs: average file size: (-f) 16384 >> tunefs: average number of files in a directory: (-s) 64 >> tunefs: minimum percentage of free space: (-m) 8% >> tunefs: space to hold for metadata blocks: (-k) 6408 >> tunefs: optimization preference: (-o) time >> tunefs: volume label: (-L) rootfs > Cheers, > > Paul. It DOES on the "clone"! It ALSO does on the "a" partition of the clone. This implies that gpart screwed up the partitioning, but THAT leaves open how and why the original partitioning (which is defined here https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi%202%20image) works at all, since that's what I'm doing -- and yet it gives the results as above (and no boot when I'm done.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040105040309050805020600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTQwMjQ0MThaME8GCSqGSIb3DQEJBDFCBECd T5bzefdGU5n1gPltX9YrkyKJhaFbZyHbeypm7VnX/i/fJ6dZKXAcXjAfpJc1Pfx6Bw/5OHZe ptfiyHksUzdiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAgnYYB88v Fkj+SILDl1Ig82KqXtHZB0NRCBwwyJgKpn9FyHQ2WVwZf/UTPt9PaOF6koKHodx90EbaE+U6 sJnbXjc4M0SpPwvA+7PvXOLCMjbp4L6U6xiGLJl47JcrjSym/dASUSDXi8qwbu4bsK+hsbRQ Ctk9rTU+R22HSp/WXNFHoVrcLzUbpEMbWoXozBbkWSY5/H8HtqkFSCRpBs/rXSMVYz2HATQf hVxsoqr0rGvchSU8BuLBpiIP+MjDChRB0qwKdb6VrrpuMN55bmoRrJdZRrEBVDKYSJY1kFdg Rir2TwS4uwAVb9Qrdkaiea4wEZgAq3rcBucjEklYj/CcnvMPpll/7f9vBlqDyhP9LSs7x47U EfuwXq0Pkiex3PltOw165RyPqdLuxciWnTVpQlxJYC9GC/H3CejUIgE9ccWGliFPhcqHPudJ a2A789f25K/tuqtZwHqpu/jjEqWdj0acDYUuNyxIszLyCVW8br/DDr3xXFTwWnT3HhPwhh3D oYSB5xQUTPH89KGr1tPqS6VQVPZfqTlvuFxc9fKC+PwimwOT2cav3EH9i47EY4GgrDd4j/mL bq7Aw7TvyHhZr0ppfDeU3dptmIWrXNhTzO3dvQqn6L2IdAckrOdYbmvb+hhgIiR7/EEytF6Y UcxTINR6UGc+OgdttPZdAMufd7EAAAAAAAA= --------------ms040105040309050805020600-- From owner-freebsd-arm@freebsd.org Thu Jul 14 06:53:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 205E4B98407 for ; Thu, 14 Jul 2016 06:53:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 BBF821A6F for ; Thu, 14 Jul 2016 06:53:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6416 invoked from network); 14 Jul 2016 06:46:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Jul 2016 06:46:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 14 Jul 2016 02:46:42 -0400 (EDT) Received: (qmail 29570 invoked from network); 14 Jul 2016 06:46:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Jul 2016 06:46:42 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 3C1BDB1E001; Wed, 13 Jul 2016 23:46:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc int instead of 32-bit SYSVR4's long and 64-bit ELF V2 long] From: Mark Millard In-Reply-To: Date: Wed, 13 Jul 2016 23:46:35 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, freebsd-arm , FreeBSD PowerPC ML , Bruce Evans , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <3DFF1DC9-2AE6-498A-9FE0-4970E76F8AB5@dsl-only.net> References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> To: Andrey Chernov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 06:53:19 -0000 On 2016-Jul-13, at 6:00 PM, Andrey Chernov wrote: > On 13.07.2016 11:53, Mark Millard wrote: >> [The below does note that TARGET=3Dpowerpc has a mix of signed = wchar_t and unsigned char types and most architectures have both being = signed types.] >=20 > POSIX says nothing about wchar_t and char should be the same = (un)signed. > It is arm ABI docs may say so only. They are different entities > differently encoded and cross assigning between wchar_t and char is = not > recommended. [My "odd" would better have been the longer phrase "unusual for FreeBSD" = for the signed type mismatch point.] C11 (9899:2011[2012]) and C++11 (14882:2011(E)) agree with your POSIX = note: no constraint to have the same signed type status as char. But when I then looked at the "System V Application Binary Interface = PowerpC Processor Supplement" (1995-Sept SunSoft document) that I = believe FreeBSD uses for powerpc (32-bit only: TARGET_ARCH=3Dpowerpc) it = has: typedef long wchar_t; as part of: Figure 6-39 (page labeled 6-38). While agreeing about the signed-type status for wchar_t this does not = agree with FreeBSD 11.0's use of int as the type: sys/powerpc/include/_types.h:typedef int ___wchar_t; sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . I'm not as sure of which document is official for TARGET_ARCH=3Dpowerpc64 = but using "Power Architecture 64-bit ELF V2 ABI Specification" (Open = POWER ABI for Linux Supplement) as an example of what likely is common = for that context: 5.1.3 Types Defined in Standard header lists: typedef long wchar_t; which again does not agree with FreeBSD 11.0's use of int as the type: # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . =3D=3D=3D Mark Millard markmi at dsl-only.net >=20 > On 2016-Jul-11, at 8:57 PM, Andrey Chernov = wrote: >=20 >> On 12.07.2016 5:44, Mark Millard wrote: >>> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: >>>=20 >>> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion = of >>> ___wchar_t (if that is distinct). >>> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; = not >>> necessarily a valid char value >>> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; = not >>> necessarily a valid char value >>=20 >> It seems you are right about "not a valid char value", I'll back this >> change out. >>=20 >>> As far as I know arm FreeBSD uses unsigned character types (of = whatever >>> width). >>=20 >> Probably it should be unsigned for other architectures too, clang = does >> not generate negative values with L'' literals and locale use = only >> positive values too. >=20 > Looking around: >=20 > # grep -i wchar sys/*/include/_types.h > sys/arm/include/_types.h:typedef unsigned int ___wchar_t; > sys/arm/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ > sys/arm/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ > sys/arm64/include/_types.h:typedef unsigned int ___wchar_t; > sys/arm64/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ > sys/arm64/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ > sys/mips/include/_types.h:typedef int ___wchar_t; > sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ > sys/powerpc/include/_types.h:typedef int ___wchar_t; > sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ > sys/riscv/include/_types.h:typedef int ___wchar_t; > sys/riscv/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/riscv/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ > sys/sparc64/include/_types.h:typedef int ___wchar_t; > sys/sparc64/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/sparc64/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ > sys/x86/include/_types.h:typedef int ___wchar_t; > sys/x86/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/x86/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >=20 > So only arm and arm64 have unsigned wchar_t types. >=20 > [NOTE: __CHAR16_TYPE__ and __CHAR32_TYPE__ are always unsigned: in = C++11 terms char16_t is like std::uint_least16_t and char32_t is like = std::uint_least32_t despite being distinct types. So __CHAR16_TYPE__ and = __CHAR32_TYPE__ are ignored below.] >=20 > The clang 3.8.0 compiler output has an odd mix for TARGET_ARCH=3Dpowerpc= and TARGET_ARCH=3Dpowerpc64 . . . >=20 > armv6 has unsigned types for both char and __WCHAR_TYPE__. > aarch64 has unsigned types for both char and __WCHAR_TYPE__. > powerpc has unsigned for char but signed for __WCHAR_TYPE__. > powerpc64 has unsigned for char but signed for __WCHAR_TYPE__. > amd64 has signed types for both char and __WCHAR_TYPE__. > i386 has signed types for both char and __WCHAR_TYPE__. > mips has signed types for both char and __WCHAR_TYPE__. > sparc64 has signed types for both char and __WCHAR_TYPE__. > (riscv is not covered by clang as I understand) >=20 > The details via compiler #define's. . . >=20 > # clang --target=3Darmv6-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 4294967295U > #define __WCHAR_TYPE__ unsigned int > #define __WCHAR_UNSIGNED__ 1 > #define __WCHAR_WIDTH__ 32 > . . . >=20 > # clang --target=3Daarch64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 4294967295U > #define __WCHAR_TYPE__ unsigned int > #define __WCHAR_UNSIGNED__ 1 > #define __WCHAR_WIDTH__ 32 > . . . >=20 > # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 > Is powerpc wrong? >=20 > # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < = /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 > Is powerpc64 wrong? >=20 >=20 > # clang --target=3Damd64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . >=20 > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 > # clang --target=3Di386-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . >=20 > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 >=20 > # clang --target=3Dmips-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . >=20 > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 > # clang --target=3Dsparc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . >=20 > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 From owner-freebsd-arm@freebsd.org Thu Jul 14 09:53:40 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10E87B92D70 for ; Thu, 14 Jul 2016 09:53:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 B3BE01A65 for ; Thu, 14 Jul 2016 09:53:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31208 invoked from network); 14 Jul 2016 09:53:32 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Jul 2016 09:53:32 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 14 Jul 2016 05:53:37 -0400 (EDT) Received: (qmail 1143 invoked from network); 14 Jul 2016 09:53:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Jul 2016 09:53:36 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id BC0BEB1E001; Thu, 14 Jul 2016 02:53:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc int instead of 32-bit SYSVR4's long and 64-bit ELF V2 long] From: Mark Millard In-Reply-To: <3DFF1DC9-2AE6-498A-9FE0-4970E76F8AB5@dsl-only.net> Date: Thu, 14 Jul 2016 02:53:29 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Bruce Evans Content-Transfer-Encoding: quoted-printable Message-Id: <580A746B-3F02-44FA-AB2E-20CC71A1E9D2@dsl-only.net> References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> <3DFF1DC9-2AE6-498A-9FE0-4970E76F8AB5@dsl-only.net> To: Andrey Chernov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 09:53:40 -0000 [Top post of a history note for powerpc and wchar_t's type in FreeBSD. = The history is from looking around in svn.] [The below is not a complaint or a request for a change. It just looks = like int for wchar_t for powerpc was a choice made long ago for simpler = code given FreeBSD's pre-existing structure.] int being used for powerpc wchar_t on FreeBSD goes back to at least = 2001-Jan-1. [FYI: "27 February, 2008: FreeBSD 7.0 is the first release = to officially support the FreeBSD/ppc port". So long before official = support.] wchar_t's type is one place where FreeBSD choose to override the powerpc = (and powerpc64) ABI standards (that indicate long, not int). I'm not = sure if this was implicit vs. explicitly realizing the ABI mismatch. = [The SYSVR4 32-bit powerpc ABI goes back to 1995.] I first traced the history back to 2002-Aug-23: -r102315 of = sys/sys/_types.h standardized FreeBSD on the following until the ARM = change: typedef int __ct_rune_t; typedef __ct_rune_t __rune_t; typedef __ct_rune_t __wchar_t; typedef __ct_rune_t __wint_t; Prior to this there was 2002-Aug-21's -r102227 = sys/powerpc/include/_types.h that used __int32_t. Prior to that had ansi.h and types.h instead of _types.h --and ansi.h = had: #define _BSD_WCHAR_T_ _BSD_CT_RUNE_T_ /* wchar_t (see below) = */ . . . #define _BSD_CT_RUNE_T_ int /* arg type for ctype = funcs */ Going back to sys/powerpc/include/ansi.h's -r70571 (2001-Jan-1 creation = in svn): #define _BSD_WCHAR_T_ int /* wchar_t */ And the comments back then say: . . . It is not * unsigned so that EOF (-1) can be naturally assigned to it and used. . . . The reason an int was * chosen over a long is that the is*() and to*() routines take ints = (says * ANSI C), but they use __ct_rune_t instead of int. I've decided to not go any farther back in time (if there is prior = history for wchar_t for powerpc). Ignoring the temporary __int32_t use: FreeBSD has had its own powerpc = wchar_t type (int) for at least the last 15 years, at least when viewed = just relative to the powerpc ABI(s) FreeBSD is based on for powerpc. Modern gcc versions even have the FreeBSD wchar_t type correct for = powerpc variants in recent times: int. Previously some notation (L based = notation) used the wrong type for one of the powerpc variants (32-bit = vs. 64-bit), causing lots of false-positive compiler notices. gcc had = followed the ABI involved (long int) until the correction. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jul-13, at 11:46 PM, Mark Millard = wrote: > On 2016-Jul-13, at 6:00 PM, Andrey Chernov = wrote: >=20 >> On 13.07.2016 11:53, Mark Millard wrote: >>> [The below does note that TARGET=3Dpowerpc has a mix of signed = wchar_t and unsigned char types and most architectures have both being = signed types.] >>=20 >> POSIX says nothing about wchar_t and char should be the same = (un)signed. >> It is arm ABI docs may say so only. They are different entities >> differently encoded and cross assigning between wchar_t and char is = not >> recommended. >=20 > [My "odd" would better have been the longer phrase "unusual for = FreeBSD" for the signed type mismatch point.] >=20 > C11 (9899:2011[2012]) and C++11 (14882:2011(E)) agree with your POSIX = note: no constraint to have the same signed type status as char. >=20 > But when I then looked at the "System V Application Binary Interface = PowerpC Processor Supplement" (1995-Sept SunSoft document) that I = believe FreeBSD uses for powerpc (32-bit only: TARGET_ARCH=3Dpowerpc) it = has: >=20 > typedef long wchar_t; >=20 > as part of: Figure 6-39 (page labeled 6-38). >=20 > While agreeing about the signed-type status for wchar_t this does not = agree with FreeBSD 11.0's use of int as the type: >=20 > sys/powerpc/include/_types.h:typedef int ___wchar_t; > sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >=20 > # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . >=20 > I'm not as sure of which document is official for = TARGET_ARCH=3Dpowerpc64 but using "Power Architecture 64-bit ELF V2 ABI = Specification" (Open POWER ABI for Linux Supplement) as an example of = what likely is common for that context: 5.1.3 Types Defined in Standard = header lists: >=20 > typedef long wchar_t; >=20 > which again does not agree with FreeBSD 11.0's use of int as the type: >=20 > # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < = /dev/null | more > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 >>=20 >> On 2016-Jul-11, at 8:57 PM, Andrey Chernov = wrote: >>=20 >>> On 12.07.2016 5:44, Mark Millard wrote: >>>> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: >>>>=20 >>>> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion = of >>>> ___wchar_t (if that is distinct). >>>> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; = not >>>> necessarily a valid char value >>>> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; = not >>>> necessarily a valid char value >>>=20 >>> It seems you are right about "not a valid char value", I'll back = this >>> change out. >>>=20 >>>> As far as I know arm FreeBSD uses unsigned character types (of = whatever >>>> width). >>>=20 >>> Probably it should be unsigned for other architectures too, clang = does >>> not generate negative values with L'' literals and locale use = only >>> positive values too. >>=20 >> Looking around: >>=20 >> # grep -i wchar sys/*/include/_types.h >> sys/arm/include/_types.h:typedef unsigned int ___wchar_t; >> sys/arm/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ >> sys/arm/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ >> sys/arm64/include/_types.h:typedef unsigned int ___wchar_t; >> sys/arm64/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ >> sys/arm64/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ >> sys/mips/include/_types.h:typedef int ___wchar_t; >> sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >> sys/powerpc/include/_types.h:typedef int ___wchar_t; >> sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >> sys/riscv/include/_types.h:typedef int ___wchar_t; >> sys/riscv/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/riscv/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >> sys/sparc64/include/_types.h:typedef int ___wchar_t; >> sys/sparc64/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/sparc64/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >> sys/x86/include/_types.h:typedef int ___wchar_t; >> sys/x86/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/x86/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >>=20 >> So only arm and arm64 have unsigned wchar_t types. >>=20 >> [NOTE: __CHAR16_TYPE__ and __CHAR32_TYPE__ are always unsigned: in = C++11 terms char16_t is like std::uint_least16_t and char32_t is like = std::uint_least32_t despite being distinct types. So __CHAR16_TYPE__ and = __CHAR32_TYPE__ are ignored below.] >>=20 >> The clang 3.8.0 compiler output has an odd mix for = TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 . . . >>=20 >> armv6 has unsigned types for both char and __WCHAR_TYPE__. >> aarch64 has unsigned types for both char and __WCHAR_TYPE__. >> powerpc has unsigned for char but signed for __WCHAR_TYPE__. >> powerpc64 has unsigned for char but signed for __WCHAR_TYPE__. >> amd64 has signed types for both char and __WCHAR_TYPE__. >> i386 has signed types for both char and __WCHAR_TYPE__. >> mips has signed types for both char and __WCHAR_TYPE__. >> sparc64 has signed types for both char and __WCHAR_TYPE__. >> (riscv is not covered by clang as I understand) >>=20 >> The details via compiler #define's. . . >>=20 >> # clang --target=3Darmv6-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more >> . . . >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> #define __CHAR_UNSIGNED__ 1 >> . . . >> #define __WCHAR_MAX__ 4294967295U >> #define __WCHAR_TYPE__ unsigned int >> #define __WCHAR_UNSIGNED__ 1 >> #define __WCHAR_WIDTH__ 32 >> . . . >>=20 >> # clang --target=3Daarch64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more >> . . . >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> #define __CHAR_UNSIGNED__ 1 >> . . . >> #define __WCHAR_MAX__ 4294967295U >> #define __WCHAR_TYPE__ unsigned int >> #define __WCHAR_UNSIGNED__ 1 >> #define __WCHAR_WIDTH__ 32 >> . . . >>=20 >> # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more >> . . . >> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> #define __CHAR_UNSIGNED__ 1 >> . . . >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >> Is powerpc wrong? >>=20 >> # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < = /dev/null | more >> . . . >> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> #define __CHAR_UNSIGNED__ 1 >> . . . >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >> Is powerpc64 wrong? >>=20 >>=20 >> # clang --target=3Damd64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more >> . . . >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> . . . (note the lack of __CHAR_UNSIGNED__) . . . >>=20 >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >> # clang --target=3Di386-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more >> . . . >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> . . . (note the lack of __CHAR_UNSIGNED__) . . . >>=20 >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >>=20 >> # clang --target=3Dmips-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more >> . . . >> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> . . . (note the lack of __CHAR_UNSIGNED__) . . . >>=20 >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >> # clang --target=3Dsparc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more >> . . . >> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> . . . (note the lack of __CHAR_UNSIGNED__) . . . >>=20 >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jul 14 15:07:12 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91F32B973EB; Thu, 14 Jul 2016 15:07:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 601881EA5; Thu, 14 Jul 2016 15:07:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: by mail-pa0-x232.google.com with SMTP id ks6so29581313pab.0; Thu, 14 Jul 2016 08:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=5PofZBAjQPsf29zDC0ldF6TNt6C4W2cSYcs9f8dQEsM=; b=UP91dJB9mvIQzm34CGJ31f18tB5sxR4zFBp6hKb3yAkKTXIc0zU6P02acvbHkedqHP CmzURlpREtNpPzHDUyJtufGG6v/alhWKFLheFxZ8Ka64zdIs0QkNhA6HwyM8kEZKGIJV O/zwHiWwE1zASw1u29fWBSkF5H/QnTbVyfj91MasyTO5AP0Lp3rgCRsNmN9pkJmj0WlO TsvrrfJLosf1/QavMDeXzujyUjlGFwaG9JHohUgC/5nBoI115Hdhahsx274INVft/2vO wBwnFZrKIP9NYlh2Q3jBW2MYdk8i4rkzufgGDPZm7eJd9A73cLpg684RO2TzplXWeUkd hjvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=5PofZBAjQPsf29zDC0ldF6TNt6C4W2cSYcs9f8dQEsM=; b=LPhVb+Wa0s0KIfO2RQ2ruZynSzDJdyVqGWKZ8k9mjKCU81jLpKi1oWtj7Gl2mSdLR6 oLjhFJWUBvvG8byPzkf0Gi8e90Vjya/sedybJwXLtQwPUpA3M8vfF/6Lzo4kx/xxass6 sCUsIW96exE0NX185PPhQg3E+XHeWCPOSyYVbDSik9xX/Tel1r6E3APdEqgZtIyXtqF9 2OUg5sobfbwQXwTzlx4JFkTJKATD9i9yhlr8Pq51nq2f8aqGNdOTtxveD+kqLXbiWntq bUUpClFfGib1FtwLIsAx4Xp2UwOfJWzFd02q61Thp4s+pWmOsjGTU4p641WUr4fifZxt wWzg== X-Gm-Message-State: ALyK8tKyNvEJO7XkODF/G8qjljMXarNDSyP3TUZg+owlgzhB3r3BIJmBoXq2ftq55kmzhA== X-Received: by 10.66.242.166 with SMTP id wr6mr23420413pac.147.1468508831752; Thu, 14 Jul 2016 08:07:11 -0700 (PDT) Received: from [192.168.20.9] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id 9sm2424257pfo.74.2016.07.14.08.07.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jul 2016 08:07:10 -0700 (PDT) From: Ngie Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: LINT tinderbox failure on ^/stable/10 with arm Date: Thu, 14 Jul 2016 08:07:09 -0700 Message-Id: Cc: stable@freebsd.org To: FreeBSD ARM Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:07:12 -0000 Hi, I=E2=80=99ve been running =E2=80=9Cmake tinderbox=E2=80=9D = periodically on ^/stable/10 and noticed that arm.LINT has been failing = recently with kbdmux(4) at link time. I=E2=80=99ve included the failing = context below (this also can be found at = https://people.freebsd.org/~ngie/tinderbox-arm-LINT-failure.txt ). Could someone please look in to this issue? Thanks, -Ngie kbdmux.o: In function `kbdmux_modevent': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x18): undefined = reference to `kbd_get_switch' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x34): undefined = reference to `kbd_find_keyboard' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x38): undefined = reference to `kbd_get_keyboard' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x58): undefined = reference to `kbd_detach' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x74): undefined = reference to `kbd_delete_driver' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x94): undefined = reference to `kbd_add_driver' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xa8): undefined = reference to `kbd_get_switch' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x118): undefined = reference to `kbd_delete_driver' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x134): undefined = reference to `kbd_attach' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x190): undefined = reference to `kbd_detach' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1a8): undefined = reference to `kbd_delete_driver' kbdmux.o: In function `kbdmux_init': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x284): undefined = reference to `kbd_init_struct' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x2f8): undefined = reference to `kbd_set_maps' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x408): undefined = reference to `kbd_register' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x618): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_term': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x6c4): undefined = reference to `kbd_release' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x6f4): undefined = reference to `kbd_unregister' kbdmux.o: In function `kbdmux_read_char': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xcbc): undefined = reference to `genkbd_keyaction' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xdec): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_ioctl': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1024): undefined = reference to `kbd_allocate' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1028): undefined = reference to `kbd_get_keyboard' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1104): undefined = reference to `kbd_release' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1304): undefined = reference to `kbd_release' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1600): undefined = reference to `genkbd_commonioctl' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1694): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_poll': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x17c4): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_kbd_event': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1810): undefined = reference to `kbd_release' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x197c): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_kbd_intr': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x19d4): undefined = reference to `kbdsw' kbdmux.o:(.data+0x24cc): undefined reference to `genkbd_get_fkeystr' kbdmux.o:(.data+0x24d4): undefined reference to `genkbd_diag' --- kernel --- *** [kernel] Error code 1= From owner-freebsd-arm@freebsd.org Thu Jul 14 16:44:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37250B9960F for ; Thu, 14 Jul 2016 16:44:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 E2D43159D for ; Thu, 14 Jul 2016 16:44:55 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 8B292220FF0 for ; Thu, 14 Jul 2016 11:44:53 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm@freebsd.org References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> From: Karl Denninger Message-ID: <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> Date: Thu, 14 Jul 2016 11:44:53 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040705070201000600060102" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:44:56 -0000 This is a cryptographically signed message in MIME format. --------------ms040705070201000600060102 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/13/2016 21:44, Karl Denninger wrote: > > On 7/13/2016 19:13, Paul Mather wrote: >>> On Jul 13, 2016, at 3:54 PM, Karl Denninger wrot= e: >>> >>> Oh, there is one difference: >>> >>> tunefs -p on the new device *works* (no idea why however since there'= s >>> no slice there) where it FAILS on the original: >>> >>> root@Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2 >> Shouldn't this be /dev/mmcsd0s2a? You're referencing the entire BSD s= lice in the above command, not the UFS partition upon which the rootfs li= ves. > Right. Here's the issue; it doesn't work on the original disk (as it > shouldn't) on the entire BSD slice but... >>> tunefs: /dev/mmcsd0s2: could not read superblock to fill out disk >>> >>> root@Test-MCP:/home/karl # tunefs -p /dev/da0s2 >>> tunefs: POSIX.1e ACLs: (-a) disabled >>> tunefs: NFSv4 ACLs: (-N) disabled >>> tunefs: MAC multilabel: (-l) disabled >>> tunefs: soft updates: (-n) enabled >>> tunefs: soft update journaling: (-j) disabled >>> tunefs: gjournal: (-J) disabled >>> tunefs: trim: (-t) disabled >>> tunefs: maximum blocks per file in a cylinder group: (-e) 4096 >>> tunefs: average file size: (-f) 16384 >>> tunefs: average number of files in a directory: (-s) 64 >>> tunefs: minimum percentage of free space: (-m) 8% >>> tunefs: space to hold for metadata blocks: (-k) 6408 >>> tunefs: optimization preference: (-o) time >>> tunefs: volume label: (-L) rootfs >> Cheers, >> >> Paul. > It DOES on the "clone"! > > It ALSO does on the "a" partition of the clone. > > This implies that gpart screwed up the partitioning, but THAT leaves > open how and why the original partitioning (which is defined here > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi%202%20image) works > at all, since that's what I'm doing -- and yet it gives the results as > above (and no boot when I'm done.) > Ok, so what's broken here folks? This is likely to blow up soon enough on the build systems that the people who are building snapshot releases are using (once they update); I assume this is a function of some sort of change that was made somewhere upstream in the system. The format of the card has to be: 1. MBR 2. First partition is MSDOS (Type "!12") with the various boot code on it (ubldr, etc.) This is fine. 3. The second partition has to be a "BSD" format partition (old-style) 4. Inside the second partition is a "traditional" BSD labeled (bsdlabel style) partititon table. Up to #2 all goes fine on an attached SD card: # gpart show da0 =3D> 63 62552001 da0 MBR (30G) 63 102400 1 !12 (50M) 102463 62449601 - free - (30G) Now we try to create the BSD labeled piece -- I got this from the crochet disk blob creator, incidentally, along with the FreeBSD Wiki (at https://wiki.freebsd.org/FreeBSD/arm/Raspberry Pi 2 image) # gpart add -t freebsd -a 4m /dev/da0 da0s2 added # gpart create -s BSD /dev/da0s2 *gpart: geom 'da0s2': File exists* *Heh, what was that? :)* What's in here? # gpart show da0 =3D> 63 62552001 da0 MBR (30G) 63 102400 1 !12 [active] (50M) 102463 4033 - free - (2.0M) 106496 62439424 2 freebsd (30G) 62545920 6144 - free - (3.0M) Hmmmm... what do we think exists for device nodes? # ls -al /dev/da0* crw-r----- 1 root operator 0x61 Jul 13 20:28 /dev/da0 crw-r----- 1 root operator 0x64 Jul 14 15:23 /dev/da0s1 crw-r----- 1 root operator 0x66 Jul 14 15:23 /dev/da0s2 crw-r----- 1 root operator 0x67 Jul 14 15:23 /dev/da0s2a Wait a minute, I didn't create any BSD slices! WTF? # bsdlabel /dev/da0s2 # /dev/da0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 62439424 0 4.2BSD 0 0 0 c: 62439424 0 unused 0 0 # "raw" part, don't edit_ _ Oh really? How'd that get in there? And by the way, that's probably why the "add" fails (no space left and the first partition already exists= ) Further, this is *also* why I can "tunefs" the base (/dev/da0s2) because there's no offset (that is, /dev/da0s2 and /dev/da0s2a both point to the same first block) and that may be why the system refuses to boot when I'm done, as it's "tasted" the first entry, found a label and thus it's "open". In fact, that gap is *exactly* what I see when I run bsdlabel on the running card: # bsdlabel /dev/mmcsd0s2 # /dev/mmcsd0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 62443392 90 4.2BSD 0 0 0 c: 62443482 0 unused 0 0 # "raw" part, don't edit It looks like the issue is that the "gpart create -t freebsd" command stuck a partition table in there which causes the "create -s BSD" to fail= =2E Strategically dding /dev/zero to the card's first 100MB or so (beyond the DOS partition and into the label) and then *again* on the freebsd partition *but before calling gpart to put the slice table on* results in the add working properly. # gpart show da0 =3D> 63 62552001 da0 MBR (30G) 63 102400 1 !12 [active] (50M) 102463 4033 - free - (2.0M) 106496 62439424 2 freebsd (30G) 62545920 6144 - free - (3.0M) # gpart show da0s2 =3D> 0 62439424 da0s2 BSD (30G) 0 128 - free - (64K) 128 62439168 1 freebsd-ufs (30G) 62439296 128 - free - (64K) # tunefs -p /dev/da0s2 tunefs: /dev/da0s2: could not read superblock to fill out disk # tunefs -p /dev/da0s2a tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) enabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) rootfs That looks valid and now matches the other card... but..... the new (duplicated) card still hangs in the same place..... It boots, the kernel loads, the root filesystem mounts and then the system hangs right after the ue0 MAC address displays on the console. How do you get the "why" on that since I have no way to break out of whatever it is hanging on (it ignores a ^C from a USB keyboard, although it *does* know it's there and the kernel displays attach/detach messages if you plug one in or out while it's hung) and there's no error message displayed that would otherwise help? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040705070201000600060102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTQxNjQ0NTNaME8GCSqGSIb3DQEJBDFCBEB/ Dd0o4tEbjNvNd2s6ZXkos4E0OlTn/GDa+ktn2pmNeRw3t2AULRsVnbbnSaJPyh75utw66RNj qmbAvJuTfk8NMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAlu44PfXZ 1zGjJFXo8K+GQ8/pHLsv5GqzTGXX/SK2JOCqgHMESzjEnGJCFIEKPlNpSUDMJPoOOZ6dqiyI NjyiNPkkRsmTTMpYlAVCn84zXfyYkD51RBQDL5yHm84dcb984fQz4V3ShhOOvanlk7U/Mqny 3esnphXsgCzwFCESE2UA90IP/xojFsqDk63ntjtZTfzruXwDf4SZyoWDgl6WvPEtNyuL4/Wz N1qlWfCXkhdKSvu7O+ulaa0HORYgUKkYOS8xU310vtrU0JhO12O/+ENwhSyn8chUNRGgEMaP YZrcLTt4KS+WSVvE8ZlCiqffG8X1Lob3hjrZJHtV3RxKmyXPWTc7G30Vn2taJp7P8KV+TA5K 4n8xYGx/7K8TDm0pZUnrUMrFg+BZE/txCpIhqFHvU9x/MnU+fZ5T28lTHdDerm7xU7qAjZt8 LTX6U9tIhQOIz5PMp6OC7pqmOG4P7BAirgfWSC62x/fGd3Ce5+wp/wDkgzziW1iJ7SSNI6n/ xmKDumPb+oj588PwIeM0Gtq7c473lABei048H/F2ebqhqKB1IsvDU4GiNO9hKn8zj17Rl6Ng 4CB2N7LaEPHVoQ8bgAZX9TslkBqdcTu/Icl3fvtRN8GSIPzy2MYoI+xFFmkBd0feGkaW9Xl6 9ufcAg2t5boE8kwloZ8A/8eU1SIAAAAAAAA= --------------ms040705070201000600060102-- From owner-freebsd-arm@freebsd.org Thu Jul 14 17:56:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D07C6B99D4E for ; Thu, 14 Jul 2016 17:56:01 +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 B2A641529 for ; Thu, 14 Jul 2016 17:56:01 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5672b964-49ec-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 14 Jul 2016 17:56:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6EHtrRm006934; Thu, 14 Jul 2016 11:55:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468518953.72182.219.camel@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Ian Lepore To: Karl Denninger , freebsd-arm@freebsd.org Date: Thu, 14 Jul 2016 11:55:53 -0600 In-Reply-To: <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 17:56:01 -0000 On Thu, 2016-07-14 at 11:44 -0500, Karl Denninger wrote: > On 7/13/2016 21:44, Karl Denninger wrote: > > > > On 7/13/2016 19:13, Paul Mather wrote: > > > > On Jul 13, 2016, at 3:54 PM, Karl Denninger > > > > wrote: > > > > > > > > Oh, there is one difference: > > > > > > > > tunefs -p on the new device *works* (no idea why however since > > > > there's > > > > no slice there) where it FAILS on the original: > > > > > > > > root@Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2 > > > Shouldn't this be /dev/mmcsd0s2a? You're referencing the entire > > > BSD slice in the above command, not the UFS partition upon which > > > the rootfs lives. > > Right. Here's the issue; it doesn't work on the original disk (as > > it > > shouldn't) on the entire BSD slice but... > > > > tunefs: /dev/mmcsd0s2: could not read superblock to fill out > > > > disk > > > > > > > > root@Test-MCP:/home/karl # tunefs -p /dev/da0s2 > > > > tunefs: POSIX.1e ACLs: (-a) > > > > disabled > > > > tunefs: NFSv4 ACLs: (-N) > > > > disabled > > > > tunefs: MAC multilabel: (-l) > > > > disabled > > > > tunefs: soft updates: (-n) > > > > enabled > > > > tunefs: soft update journaling: (-j) > > > > disabled > > > > tunefs: gjournal: (-J) > > > > disabled > > > > tunefs: trim: (-t) > > > > disabled > > > > tunefs: maximum blocks per file in a cylinder group: (-e) 4096 > > > > tunefs: average file size: (-f) > > > > 16384 > > > > tunefs: average number of files in a directory: (-s) 64 > > > > tunefs: minimum percentage of free space: (-m) 8% > > > > tunefs: space to hold for metadata blocks: (-k) 6408 > > > > tunefs: optimization preference: (-o) time > > > > tunefs: volume label: (-L) > > > > rootfs > > > Cheers, > > > > > > Paul. > > It DOES on the "clone"! > > > > It ALSO does on the "a" partition of the clone. > > > > This implies that gpart screwed up the partitioning, but THAT > > leaves > > open how and why the original partitioning (which is defined here > > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi%202%20image) > > works > > at all, since that's what I'm doing -- and yet it gives the results > > as > > above (and no boot when I'm done.) > > > > Ok, so what's broken here folks? This is likely to blow up soon > enough > on the build systems that the people who are building snapshot > releases > are using (once they update); I assume this is a function of some > sort > of change that was made somewhere upstream in the system. > > The format of the card has to be: > > 1. MBR > 2. First partition is MSDOS (Type "!12") with the various boot code > on > it (ubldr, etc.) This is fine. > 3. The second partition has to be a "BSD" format partition (old > -style) > 4. Inside the second partition is a "traditional" BSD labeled > (bsdlabel > style) partititon table. > > Up to #2 all goes fine on an attached SD card: > # gpart show da0 > => 63 62552001 da0 MBR (30G) > 63 102400 1 !12 (50M) > 102463 62449601 - free - (30G) > > Now we try to create the BSD labeled piece -- I got this from the > crochet disk blob creator, incidentally, along with the FreeBSD Wiki > (at > https://wiki.freebsd.org/FreeBSD/arm/Raspberry Pi 2 image) > > # gpart add -t freebsd -a 4m /dev/da0 > da0s2 added > # gpart create -s BSD /dev/da0s2 > *gpart: geom 'da0s2': File exists* > > *Heh, what was that? :)* > There's nothing new or different-on-rpi about this. There was previously a BSD geom there. Nothing you've done with gpart up to this point changed that. As soon as you make a slice entry that once again points to where the old BSD geom is, the automatic "taste" procedure that happens after creating a new geom (the slice) finds it there and creates new geoms for it as well. When you're trying to reliably create a layout on a device regardless of what has been there in the past, this is frustrating and your inclination is to curse whoever coded such a mess. When your MBR got overwritten by accident and you restore it, and all the other data on the disk turns out to be just as intact as it ever was, your inclination is to praise whoever coded such robustness. I've been meaning to write up a wiki page or something on this for six months, but I never get around to it. So I'll just dump it out all stream-of-conciousness style here... To reliably create a new layout regardless of what may be present already on the media, you have two choices: 1 - dd zeroes to the entire device 2 - use the "no commit" feature of gpart Since #1 is impractical, here's the story with #2... When you pass no '-f ' to a gpart command, it automatically adds the "-f C" (commit) flag behind your back. There is no "don't commit" flag, so (this is surrealistically crazy...) what you're supposed to do is pass an invalid flag, which it won't complain about, in order to prevent it from automatically adding that 'C' flag you didn't even realize existed. (This is where *I* curse whoever coded this mess.) When you don't commit, the changes take place in a sort of 'virtual workspace' and nothing on the physical disk changes until you do a "gpart commit" (or "gpart undo" to discard the changes). Making all this much-less-cool that it's sounding right now, there is no automatic recursion for commit and undo... if you create a bunch of nested stuff (a slice, a geom within that slice, parititions within that geom), then you have to commit all the pending new geoms *in reverse order of how they were created*. So, using da0 (since it's shorter to type), the sequence goes like: gpart destroy -f x -F da0 gpart create -f x -s MBR da0 gpart add -f x -t \!12 -s 64M -a 4M da0 gpart add -f x -t freebsd -a 4M da0 gpart destroy -f x -F da0s2 gpart create -f x -s BSD da0s2 gpart add -f x -t freebsd-ufs da0s2 gpart commit da0s2 gpart commit da0 newfs_msdos /dev/da0s1 newfs -U /dev/da0s2a And that reliably creates a fresh rpi-style layout regardless of what was on the media before you started. Beware that if you do some gpart stuff with -f x you MUST either commit or undo, and you'd better remember which geoms need to be committed, because nothing about a gpart show will tell you what's pending. If you don't either commit or undo the pending stuff, further attempts to work with that device will just give confusing "operation not permitted" errors with no clue about why. > [snip stuff about tunefs] Now, to address the question of the filesystem existing at da0s2 versus da0s2a, the difference is alignment. Making things even more confusing, alignment (if you don't specify it) sometimes changes based on the type and brand of usb sdcard reader you're using and the fake geometry values it reports to the system. (A USB reader almost always reports different fake geometry than a native sd slot would on a machine with non-USB based sd support.) By design, dating back as long as I can remember, it has been possible for a bsdlabel and a ufs filesystem to begin at the same block on disk. The first 16K (iirc) of a ufs filesystem is never touched by ufs, specifically so that the bsdlabel can live in those blocks. My understanding of this is vague at best; I think it may have been a thing that made more sense with the tiny disks back in the 80s and 90s. So, in the command sequence above, consider these two variations of creating the ufs partition inside the bsd slice. If you do it as shown above, without aligning the partition, you get: # gpart add -f x -t freebsd-ufs da0s2 [commit, format, ...] # gpart show da0s2 => 0 31145940 da0s2 BSD (15G) 0 31145940 1 freebsd-ufs (15G) # file -s /dev/da0s2 /dev/da0s2: Unix Fast File system [v2] (little-endian) [snip] # file -s /dev/da0s2a /dev/da0s2a: Unix Fast File system [v2] (little-endian) [snip] Now if you do it with the partition aligned you get: # gpart add -f x -t freebsd-ufs -a 4M da0s2 [commit, format, ...] # gpart show da0s2 => 0 31145940 da0s2 BSD (15G) 0 8163 - free - (4.0M) 8163 31129600 1 freebsd-ufs (15G) 31137763 8177 - free - (4.0M) # file -s /dev/da0s2 /dev/da0s2: data # file -s /dev/da0s2a /dev/da0s2a: Unix Fast File system [v2] (little-endian) [snip] It's interesting that file(1) doesn't recognize a bsd label. -- Ian From owner-freebsd-arm@freebsd.org Thu Jul 14 18:27:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37BF6B99545 for ; Thu, 14 Jul 2016 18:27:38 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 C6364165A for ; Thu, 14 Jul 2016 18:27:37 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 24041224473 for ; Thu, 14 Jul 2016 13:27:35 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm@freebsd.org References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> From: Karl Denninger Message-ID: <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> Date: Thu, 14 Jul 2016 13:27:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1468518953.72182.219.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080000060206080005050305" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 18:27:38 -0000 This is a cryptographically signed message in MIME format. --------------ms080000060206080005050305 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/14/2016 12:55, Ian Lepore wrote: > On Thu, 2016-07-14 at 11:44 -0500, Karl Denninger wrote: >> On 7/13/2016 21:44, Karl Denninger wrote: >>> On 7/13/2016 19:13, Paul Mather wrote: >>>>> On Jul 13, 2016, at 3:54 PM, Karl Denninger >>>>> wrote: >>>>> Oh, there is one difference: >>>>> >>>>> tunefs -p on the new device *works* (no idea why however since >>>>> there's >>>>> no slice there) where it FAILS on the original: >>>>> >>>>> root@Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2 >>>> Shouldn't this be /dev/mmcsd0s2a? You're referencing the entire >>>> BSD slice in the above command, not the UFS partition upon which >>>> the rootfs lives. >>> Right. Here's the issue; it doesn't work on the original disk (as >>> it >>> shouldn't) on the entire BSD slice but... >>>>> tunefs: /dev/mmcsd0s2: could not read superblock to fill out >>>>> disk >>>>> >>>>> root@Test-MCP:/home/karl # tunefs -p /dev/da0s2 >>>>> tunefs: POSIX.1e ACLs: (-a) =20 >>>>> disabled >>>>> tunefs: NFSv4 ACLs: (-N) =20 >>>>> disabled >>>>> tunefs: MAC multilabel: (-l) =20 >>>>> disabled >>>>> tunefs: soft updates: (-n) =20 >>>>> enabled >>>>> tunefs: soft update journaling: (-j) =20 >>>>> disabled >>>>> tunefs: gjournal: (-J) =20 >>>>> disabled >>>>> tunefs: trim: (-t) =20 >>>>> disabled >>>>> tunefs: maximum blocks per file in a cylinder group: (-e) 4096 >>>>> tunefs: average file size: (-f) =20 >>>>> 16384 >>>>> tunefs: average number of files in a directory: (-s) 64 >>>>> tunefs: minimum percentage of free space: (-m) 8% >>>>> tunefs: space to hold for metadata blocks: (-k) 6408 >>>>> tunefs: optimization preference: (-o) time >>>>> tunefs: volume label: (-L) =20 >>>>> rootfs >>>> Cheers, >>>> >>>> Paul. >>> It DOES on the "clone"! >>> >>> It ALSO does on the "a" partition of the clone. >>> >>> This implies that gpart screwed up the partitioning, but THAT >>> leaves >>> open how and why the original partitioning (which is defined here >>> https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi%202%20image) >>> works >>> at all, since that's what I'm doing -- and yet it gives the results >>> as >>> above (and no boot when I'm done.) >>> >> Ok, so what's broken here folks? This is likely to blow up soon >> enough >> on the build systems that the people who are building snapshot >> releases >> are using (once they update); I assume this is a function of some >> sort >> of change that was made somewhere upstream in the system. >> >> The format of the card has to be: >> >> 1. MBR >> 2. First partition is MSDOS (Type "!12") with the various boot code >> on >> it (ubldr, etc.) This is fine. >> 3. The second partition has to be a "BSD" format partition (old >> -style) >> 4. Inside the second partition is a "traditional" BSD labeled >> (bsdlabel >> style) partititon table. >> >> Up to #2 all goes fine on an attached SD card: >> # gpart show da0 >> =3D> 63 62552001 da0 MBR (30G) >> 63 102400 1 !12 (50M) >> 102463 62449601 - free - (30G) >> >> Now we try to create the BSD labeled piece -- I got this from the >> crochet disk blob creator, incidentally, along with the FreeBSD Wiki >> (at >> https://wiki.freebsd.org/FreeBSD/arm/Raspberry Pi 2 image) >> >> # gpart add -t freebsd -a 4m /dev/da0 >> da0s2 added >> # gpart create -s BSD /dev/da0s2 >> *gpart: geom 'da0s2': File exists* >> >> *Heh, what was that? :)* >> > There's nothing new or different-on-rpi about this. There was > previously a BSD geom there.=20 No there wasn't. It was a blank (brand new) card the first time around; it had a MSDOS filesystem on it (as do all new cards) but *no* BSD-specific geom anything on it. > To reliably create a new layout regardless of what may be present > already on the media, you have two choices: > > 1 - dd zeroes to the entire device > 2 - use the "no commit" feature of gpart Actually in the case at hand #1 isn't impractical since I really only care about the first 100MB or so being zeroed. The reason is that my boot block (the MSDOS fs) is ~50Mb and the label is obviously next, so if we zero the first 100MB we're fine. And in fact that does work. > When you pass no '-f ' to a gpart command, it automatically adds= > the "-f C" (commit) flag behind your back. There is no "don't commit" > flag, so (this is surrealistically crazy...) what you're supposed to do= > is pass an invalid flag, which it won't complain about, in order to > prevent it from automatically adding that 'C' flag you didn't even > realize existed. (This is where *I* curse whoever coded this mess.) > > When you don't commit, the changes take place in a sort of 'virtual > workspace' and nothing on the physical disk changes until you do a > "gpart commit" (or "gpart undo" to discard the changes). Making all > this much-less-cool that it's sounding right now, there is no automatic= > recursion for commit and undo... if you create a bunch of nested stuff > (a slice, a geom within that slice, parititions within that geom), then= > you have to commit all the pending new geoms *in reverse order of how > they were created*. > > So, using da0 (since it's shorter to type), the sequence goes like: > > gpart destroy -f x -F da0 > gpart create -f x -s MBR da0 > gpart add -f x -t \!12 -s 64M -a 4M da0 > gpart add -f x -t freebsd -a 4M da0 > gpart destroy -f x -F da0s2 > gpart create -f x -s BSD da0s2 > gpart add -f x -t freebsd-ufs da0s2 > gpart commit da0s2 > gpart commit da0 > newfs_msdos /dev/da0s1 > newfs -U /dev/da0s2a > > And that reliably creates a fresh rpi-style layout regardless of what > was on the media before you started. Ok, I will try this, BUT I suspect it's still screwed (blind) because when I zeroed the front of the disk I got a "correct" partition layout but after populating it what I get still hangs after it mounts root in the same place. The way to prevent the alignment issue from coming up is to specify a "-b" switch on the "add", giving you a block offset.=20 "-b 64" is sufficient; now if the system tries to "taste" da0s2 it will fail (as it does for the card that is running) but "tasting" da0s2a succeeds. > Now, to address the question of the filesystem existing at da0s2 versus= > da0s2a, the difference is alignment. Making things even more > confusing, alignment (if you don't specify it) sometimes changes based > on the type and brand of usb sdcard reader you're using and the fake > geometry values it reports to the system. (A USB reader almost always > reports different fake geometry than a native sd slot would on a > machine with non-USB based sd support.) Yes, I understand that; if the alignment matches thus the "a" partition starts at offset zero then you can actually reference that (although length might be wrong) with the base device. After all, what it really does is look at the blocks to see if the magic number is good, and if so it tries to read and process it. But this doesn't explain why, after getting a layout that's correct (by writing zeros to the front of the card first, so anything that "might" be there isn't) and copying all the file structure over (which facially not only appears to be correct but the loader finds and loads the kernel, AND the root filesystem mounts!) the system hangs, apparently just before init gets started. If init can't be found you should get a complaint (been there, done that) on the console but there is no complaint of any sort. I've gotten through the bad structure issue on the SD card, and am now left with "why does it hang on boot -- with no error or other indication of what the problem is" after the kernel loads *and* the root filesystem mounts? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080000060206080005050305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTQxODI3MzVaME8GCSqGSIb3DQEJBDFCBECr KgludZbd+i5FfLayqTbe0byi+Fqvq2LhwPwuQ0k1ngJNSS9ITfbiJaaneB7KAc6Ge7aIGJBZ CA2hTgkgCfygMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAah29Ii30 Au6YvejxiUocOMZrtDgx4LA7dy17YKMWggI131TXWC9OQWvcaiX4GmvW7HlSsfKx7GShiaaN B/kaNNxYI1gAcJnZvHEilIV/QYo3YmCaGior1+Ew5i2k8DnIn/KkdVKs8geYiL4UU/nvcdnV ya3O/BIw9LfIc3014Fln6RowCkjkhMoarnY3hIbLzVcJrLw549jR1xlcnLAMhYPMYTpK9bYI gO32MCSEyQYyRJzBg9cZ1Z4cFr76Xcx2sGtfqg3YmtvI6/PreLkZJxHb3ND0WFMhcMt/2WrI CGTjz9dg2F2MS498ertLfLHRagIcOiz6vlNcRDVuZXa9fuA45YENJinrL+bB56uII7r/3xAa 51ORqqpGa12BEZQFMoY8XYhPr1RNWPUFowsls/w5vh9u0hxxi8iAjjxYObkw5ho4liyBxP6O Z3zN8zvSN+jVlZa28Yrcv1H71GSxqny6wk2MTxEmSfeiHDnI0RNHqY7lz58Wq43g7Zps4VB4 5YlWyijl5QyUHBZw3/ZP3NNgqCNl5NH60vQ281tOHP/ijzDB82v9ZXdRTGG45LHq9CesZ9lT Pf+j1uMnM/c4bSryXhuy1vdBGl94RDe/xAN7kp/d0WTPq8TbvkRoYTVoR26KKbOo0+IEVYzL 8wiQFRHG7gket4UOtfBQEXw3y8AAAAAAAAA= --------------ms080000060206080005050305-- From owner-freebsd-arm@freebsd.org Thu Jul 14 20:45:06 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63578B99F32 for ; Thu, 14 Jul 2016 20:45:06 +0000 (UTC) (envelope-from switchedon@portfolio.servers.prgn.misp.co.uk) Received: from portfolio.servers.prgn.misp.co.uk (portfolio.servers.prgn.misp.co.uk [95.142.155.147]) (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 28C391531 for ; Thu, 14 Jul 2016 20:45:05 +0000 (UTC) (envelope-from switchedon@portfolio.servers.prgn.misp.co.uk) Received: from switchedon by portfolio.servers.prgn.misp.co.uk with local (Exim 4.87) (envelope-from ) id 1bNmE4-00009C-4F for freebsd-arm@freebsd.org; Thu, 14 Jul 2016 20:23:12 +0100 To: freebsd-arm@freebsd.org Subject: Delivery Notification, ID 00000830549 Date: Thu, 14 Jul 2016 19:23:12 +0000 From: "FedEx International Next Flight" Reply-To: "FedEx International Next Flight" Message-ID: X-Priority: 3 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portfolio.servers.prgn.misp.co.uk X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [514 515] / [47 12] X-AntiAbuse: Sender Address Domain - portfolio.servers.prgn.misp.co.uk X-Get-Message-Sender-Via: portfolio.servers.prgn.misp.co.uk: authenticated_id: switchedon/from_h X-Authenticated-Sender: portfolio.servers.prgn.misp.co.uk: tom.greer@switchedonyoungpeople.co.uk Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 20:45:06 -0000 Dear Customer, Courier was unable to deliver the parcel to you. Please, download Delivery Label attached to this email. Yours sincerely, Tom Greer, FedEx Station Manager. From owner-freebsd-arm@freebsd.org Thu Jul 14 21:31:21 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03EA0B99D1F for ; Thu, 14 Jul 2016 21:31:21 +0000 (UTC) (envelope-from 115787@hewsl06.webreus.nl) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E2C4A1257 for ; Thu, 14 Jul 2016 21:31:20 +0000 (UTC) (envelope-from 115787@hewsl06.webreus.nl) Received: by mailman.ysv.freebsd.org (Postfix) id E22C5B99D1E; Thu, 14 Jul 2016 21:31:20 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1D2AB99D1B for ; Thu, 14 Jul 2016 21:31:20 +0000 (UTC) (envelope-from 115787@hewsl06.webreus.nl) Received: from mail-out.webreus.nl (mail-out.webreus.nl [46.235.46.204]) by mx1.freebsd.org (Postfix) with ESMTP id 471D71254 for ; Thu, 14 Jul 2016 21:31:19 +0000 (UTC) (envelope-from 115787@hewsl06.webreus.nl) Received: from hewsl06.webreus.nl (hewsl06.webreus.nl [46.235.46.54]) by mail-out.webreus.nl (Postfix) with ESMTP id 72CA43836E0DF for ; Thu, 14 Jul 2016 23:10:14 +0200 (CEST) Received: by hewsl06.webreus.nl (Postfix, from userid 115787) id 5C73B14175F; Thu, 14 Jul 2016 23:10:14 +0200 (CEST) To: arm@freebsd.org Subject: Delivery Notification, ID 00962051 X-PHP-Script: tekstschrijverij.nl/post.php for 173.254.28.145 Date: Thu, 14 Jul 2016 23:10:14 +0200 From: "FedEx Standard Overnight" Reply-To: "FedEx Standard Overnight" Message-ID: <99438e7b9914470dd502bd9edd47de1c@tekstschrijverij.nl> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 21:31:21 -0000 Dear Customer, We could not deliver your parcel. Shipment Label is attached to this email. Warm regards, Kevin Bauer, Sr. Delivery Agent. From owner-freebsd-arm@freebsd.org Fri Jul 15 03:36:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDB5AB9808E for ; Fri, 15 Jul 2016 03:36:44 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 9E2DF1DD0 for ; Fri, 15 Jul 2016 03:36:44 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id E1E892240D6 for ; Thu, 14 Jul 2016 22:36:35 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm@freebsd.org References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> From: Karl Denninger Message-ID: Date: Thu, 14 Jul 2016 22:36:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060700030308030407000306" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 03:36:45 -0000 This is a cryptographically signed message in MIME format. --------------ms060700030308030407000306 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/14/2016 13:27, Karl Denninger wrote: > On 7/14/2016 12:55, Ian Lepore wrote: > No there wasn't. It was a blank (brand new) card the first time around= ; > it had a MSDOS filesystem on it (as do all new cards) but *no* > BSD-specific geom anything on it. >> To reliably create a new layout regardless of what may be present >> already on the media, you have two choices: >> >> 1 - dd zeroes to the entire device >> 2 - use the "no commit" feature of gpart > Actually in the case at hand #1 isn't impractical since I really only > care about the first 100MB or so being zeroed. The reason is that my > boot block (the MSDOS fs) is ~50Mb and the label is obviously next, so > if we zero the first 100MB we're fine. > > And in fact that does work. >> When you pass no '-f ' to a gpart command, it automatically add= s >> the "-f C" (commit) flag behind your back. There is no "don't commit"= >> flag, so (this is surrealistically crazy...) what you're supposed to d= o >> is pass an invalid flag, which it won't complain about, in order to >> prevent it from automatically adding that 'C' flag you didn't even >> realize existed. (This is where *I* curse whoever coded this mess.) >> >> When you don't commit, the changes take place in a sort of 'virtual >> workspace' and nothing on the physical disk changes until you do a >> "gpart commit" (or "gpart undo" to discard the changes). Making all >> this much-less-cool that it's sounding right now, there is no automati= c >> recursion for commit and undo... if you create a bunch of nested stuff= >> (a slice, a geom within that slice, parititions within that geom), the= n >> you have to commit all the pending new geoms *in reverse order of how >> they were created*. >> >> So, using da0 (since it's shorter to type), the sequence goes like: >> >> gpart destroy -f x -F da0 >> gpart create -f x -s MBR da0 >> gpart add -f x -t \!12 -s 64M -a 4M da0 >> gpart add -f x -t freebsd -a 4M da0 >> gpart destroy -f x -F da0s2 >> gpart create -f x -s BSD da0s2 >> gpart add -f x -t freebsd-ufs da0s2 >> gpart commit da0s2 >> gpart commit da0 >> newfs_msdos /dev/da0s1 >> newfs -U /dev/da0s2a >> >> And that reliably creates a fresh rpi-style layout regardless of what >> was on the media before you started. > Ok, I will try this, BUT I suspect it's still screwed (blind) because > when I zeroed the front of the disk I got a "correct" partition layout > but after populating it what I get still hangs after it mounts root in > the same place. The way to prevent the alignment issue from coming up > is to specify a "-b" switch on the "add", giving you a block offset.=20 > "-b 64" is sufficient; now if the system tries to "taste" da0s2 it will= > fail (as it does for the card that is running) but "tasting" da0s2a > succeeds. >> Now, to address the question of the filesystem existing at da0s2 versu= s >> da0s2a, the difference is alignment. Making things even more >> confusing, alignment (if you don't specify it) sometimes changes based= >> on the type and brand of usb sdcard reader you're using and the fake >> geometry values it reports to the system. (A USB reader almost always= >> reports different fake geometry than a native sd slot would on a >> machine with non-USB based sd support.) > Yes, I understand that; if the alignment matches thus the "a" partition= > starts at offset zero then you can actually reference that (although > length might be wrong) with the base device. After all, what it really= > does is look at the blocks to see if the magic number is good, and if s= o > it tries to read and process it. > > But this doesn't explain why, after getting a layout that's correct (by= > writing zeros to the front of the card first, so anything that "might" > be there isn't) and copying all the file structure over (which facially= > not only appears to be correct but the loader finds and loads the > kernel, AND the root filesystem mounts!) the system hangs, apparently > just before init gets started. > > If init can't be found you should get a complaint (been there, done > that) on the console but there is no complaint of any sort. > > I've gotten through the bad structure issue on the SD card, and am now > left with "why does it hang on boot -- with no error or other indicatio= n > of what the problem is" after the kernel loads *and* the root filesyste= m > mounts? > Found it. Apparently the current code *requires* the label be set on the msdos partition. If it's not then not only does it not mount (which shouldn't matter post-boot as the loader is supposed to pass the dtb file, it is specified in the config file without any sort of path prefix, and thus once the kernel has loaded it should not matter if the dos partition if actually mounted or not) *but* the boot process hangs without any indication of why! So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} If the "-L" is missing you're hosed; the system facially appears to be just fine but while the loader comes up and so does the kernel, it hangs without ever proceeding -- and without any sort of error message indicating that it is unable to mount something it needs. I can clone cards now. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060700030308030407000306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUwMzM2MzVaME8GCSqGSIb3DQEJBDFCBED3 2eXUs69rN4wP6UaYrq6gFMKzRf6x+1dmM50d/eEiILacJsG26+oXuCZLOWjwdYBsDaPyHSMb F6xO6kl2bWFMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAO2aRDFU3 mF+JTZ0qbiST1rRPgApWL8onamBZvPnkcpuVikKZuMMA63AZ4WPk1t+nF35/cLu0dURNVmmO G6YJ8L8m7iGrz7szgD6QSNKkK2VNR2jtUnXBw7uK+5lgh3FHyOpWgh4JTKGji75HE3QP4kS6 FE0g0CQ3LIDl97bRrxdihMixqdZ/zEyxwTeapy27Uwx3Jr/cwD9hubEznjGgxqR5pTcOx4lF qvfjelSxXazp4SONxQDJy7tW2Exzdh3Tz/VMep2YlMncH9wjaaaw+nezIWiNmVYGlg8wVvRO vf3t21PQK4MnHCjE914xhezRmnjHcZyi6b6mAYJOntc/u8qH9E/f3TbhZjUfjKQT7jvmPMlr xTT7hMbdvXYaAOQwWvcK6ZSnsQOSGXMIagozLW+U2uabcUqHaXtoxolfw65Jz1ltMPiGioJj W0sTenAqpfT/tEympSDeaJqCfJcYg7OFaN3GVdFbACp7k0OstKfio2OlBA4xWLkOyJgpeedT KW6k4VJaB2EC+FDeONkkNE49tj2WghixHFH9APFSa6pWMGFFClVwKV+V6qZIghjzRnIRx6Xs LJeQ2s3we4yRrxu8RjDlRT3zcrHKMgiZ2RNUAOmcBbx5L6iRPGI4xD4lNCBRirCpvWxYXhKg JG82pU9iNyT5RtydKcGiPoCk/ssAAAAAAAA= --------------ms060700030308030407000306-- From owner-freebsd-arm@freebsd.org Fri Jul 15 04:33:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 374E9B97023 for ; Fri, 15 Jul 2016 04:33:01 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD8ED1A48 for ; Fri, 15 Jul 2016 04:33:00 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id x130so140232332vkc.0 for ; Thu, 14 Jul 2016 21:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ttgFIVJMBhIwQID7ZuW1S8FGB0XYJGpg9E467KjmSxw=; b=B5xu94oFeVnUDzmtkvNgDcJIh8De8kmpnNLrLlbo0PpaJ/CO5a0XxJ8htx+KYJwZ+w YQM8jNUD86OLFfCYoOLKPG4CaV7Kb7l8ooyrpIN+PVRuC46DCttSVaTLqff6MwLvkchA EN2DFJUh57sDL6lVTOqYri7hM60uyq7+78QW7SbQX/9eb4BfnPjgi6kc4vHYj7Mpczlt /GiZnb7IglWOGbt+N5Nb1N6cmz6iaWvMvBaGky9yH7KXa2TStX/73qQvZbZb6hSpTAEI JhSDyDr+eV9HyUj6KZR62+8QLPUO2CwJPvsJp/DyPzsvFWY+4foGF+5wiCPqABytm93X We6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ttgFIVJMBhIwQID7ZuW1S8FGB0XYJGpg9E467KjmSxw=; b=Hbz9m2w8BUSZ+L4x8CYa5FWxgwzSiSR00YdP4XA2BoC/MZOQsI/Usl+Gh6ODQI3D2H /8/6WXSjTbXC+/46ANF3TBxj8cGc8YlK7+lQ2jVG48yjnzL6LiFpH/cGq2nxzZux/wK1 HL6VZ2shyjTAZkTMt5PXTfGNkZ0k8EQhflswOnHj926+aipYTfyH9ArdoEDEnZM1uV63 WLok+qE+klKsvVRYXeJx5fy15N5CKLVklAZwXdyhk8DAM/KmeDt3OczTkLpr0SbrqQcH roF0wAnTuD288mFjB/vyW9SGk4VVmMVrRqClLMs7STDxV93FNt3vQDcBh47pcEzr0oHy lOTA== X-Gm-Message-State: ALyK8tIAQzAX0VyZsxvKzsIK7cxncNknFuuG/Kz2LuXsXgL4nsb8HJUpjcv4WEDR10OkyPKPZP9/mLj/yy3Xwg== X-Received: by 10.159.34.202 with SMTP id 68mr9006280uan.115.1468557179966; Thu, 14 Jul 2016 21:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.237 with HTTP; Thu, 14 Jul 2016 21:32:30 -0700 (PDT) In-Reply-To: <5d8ec4d4-4c36-139d-6102-4fdb200fdf65@gmail.com> References: <5d8ec4d4-4c36-139d-6102-4fdb200fdf65@gmail.com> From: Jia-Shiun Li Date: Fri, 15 Jul 2016 12:32:30 +0800 Message-ID: Subject: Re: Random number generator on rpi To: "Jukka A. Ukkonen" Cc: "freebsd-arm@freebsd.org" Content-Type: multipart/mixed; boundary=94eb2c07ae600b6c250537a51ddc X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 04:33:01 -0000 --94eb2c07ae600b6c250537a51ddc Content-Type: text/plain; charset=UTF-8 sorry for replying so late. Turns out I need to attach rndtest device to hook it on. Updated patch attached. Also commented some code lines in rndtest to print report messages. You should be able to see repeated kernel messages like below: bcmrng0: rndtest: runs pass zeros interval 1 (2343 < 2543 < 2657) bcmrng0: rndtest: runs pass zeros interval 2 (1135 < 1255 < 1365) bcmrng0: rndtest: runs pass zeros interval 3 (542 < 624 < 708) bcmrng0: rndtest: runs pass zeros interval 4 (251 < 301 < 373) bcmrng0: rndtest: runs pass zeros interval 5 (111 < 158 < 201) bcmrng0: rndtest: runs pass zeros interval 6 (111 < 149 < 201) bcmrng0: rndtest: runs pass ones interval 1 (2343 < 2535 < 2657) bcmrng0: rndtest: runs pass ones interval 2 (1135 < 1265 < 1365) bcmrng0: rndtest: runs pass ones interval 3 (542 < 576 < 708) bcmrng0: rndtest: runs pass ones interval 4 (251 < 315 < 373) bcmrng0: rndtest: runs pass ones interval 5 (111 < 185 < 201) bcmrng0: rndtest: runs pass ones interval 6 (111 < 153 < 201) bcmrng0: rndtest: chi^2(4): pass (sum 1570182) bcmrng0: rndtest: longruns pass (15 ones, 12 zeros) by the rndtest result, guess I can safely conclude the hardware rng working correctly? On Thu, Jun 9, 2016 at 3:53 PM, Jukka A. Ukkonen wrote: > > So, does this somehow indicate that fortuna has attached the > new random device as a source of true randomness? > > root@rpi2:~ # sysctl kern.random > kern.random.fortuna.minpoolsize: 64 > kern.random.harvest.mask_symbolic: > > [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > kern.random.harvest.mask_bin: 00111111111 > kern.random.harvest.mask: 511 > kern.random.random_sources: > The mask only reports environmental sources, not hardware rng sources. -Jia-Shiun. --94eb2c07ae600b6c250537a51ddc Content-Type: application/octet-stream; name="rpirng.patch" Content-Disposition: attachment; filename="rpirng.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iqn8yzhk0 SW5kZXg6IGFybS9icm9hZGNvbS9iY20yODM1L2JjbTI4MzVfcm5nLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g YXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV9ybmcuYwkobm9uZXhpc3RlbnQpCisrKyBhcm0v YnJvYWRjb20vYmNtMjgzNS9iY20yODM1X3JuZy5jCSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEs MTk4IEBACisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAxNiBKaWEtU2hpdW4gTGkgPGppYXNoaXVu QGdtYWlsLmNvbT4KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRp b24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Cisg KiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5n IGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNl IGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlz IGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICogMi4g UmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBj b3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBm b2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90 aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgorICogVEhJ UyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBB UyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJ TkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVS Q0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorICogQVJF IERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9S UyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BF Q0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcs IEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICog T1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJ TlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFC SUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JU IChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQor ICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRI RSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKi8KKyNpbmNsdWRlICJvcHRfYmNt cm5nLmgiCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KKworI2luY2x1ZGUgPHN5cy9wYXJhbS5o PgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorI2luY2x1ZGUgPHN5cy93YXRjaGRvZy5oPgorI2lu Y2x1ZGUgPHN5cy9idXMuaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lz L21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9ybWFuLmg+CisjaW5jbHVkZSA8c3lzL2NvbmYuaD4K KyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lzL3JhbmRvbS5oPgorCisjaW5j bHVkZSA8ZGV2L3JhbmRvbS9yYW5kb21kZXYuaD4KKyNpbmNsdWRlIDxkZXYvZmR0L2ZkdF9jb21t b24uaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9v ZndfYnVzLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KKworI2luY2x1ZGUg PG1hY2hpbmUvYnVzLmg+CisjaW5jbHVkZSA8bWFjaGluZS9jcHVmdW5jLmg+CisjaW5jbHVkZSA8 bWFjaGluZS9tYWNoZGVwLmg+CisKKyNpZmRlZiBCQ01STkdfUk5EVEVTVAorI2luY2x1ZGUgPGRl di9ybmR0ZXN0L3JuZHRlc3QuaD4KKyNlbmRpZgorCisjZGVmaW5lCVJFQUQoX3NjLCBfcikgYnVz X3NwYWNlX3JlYWRfNCgoX3NjKS0+YnN0LCAoX3NjKS0+YnNoLCAoX3IpKQorI2RlZmluZQlXUklU RShfc2MsIF9yLCBfdikgYnVzX3NwYWNlX3dyaXRlXzQoKF9zYyktPmJzdCwgKF9zYyktPmJzaCwg KF9yKSwgKF92KSkKKworI2RlZmluZSBSTkdfUkVHX0NUUkwJMHgwMAorI2RlZmluZSBSTkdfUkVH X1NUQVRVUwkweDA0CisjZGVmaW5lIFJOR19SRUdfREFUQQkweDA4CisKK3N0cnVjdCBiY21ybmdf c29mdGMgeworCWRldmljZV90CQlkZXY7CisJc3RydWN0IHJlc291cmNlICoJcmVzOworCWJ1c19z cGFjZV90YWdfdAkJYnN0OworCWJ1c19zcGFjZV9oYW5kbGVfdAlic2g7CisKKwlzdHJ1Y3Qgcm5k dGVzdF9zdGF0ZQkqc2Nfcm5kdGVzdDsJLyogUk5HIHRlc3Qgc3RhdGUgKi8KKwl2b2lkCQkJKCpz Y19oYXJ2ZXN0KShzdHJ1Y3Qgcm5kdGVzdF9zdGF0ZSAqLAorCQkJCQl2b2lkICosIHVfaW50KTsK KwlzdHJ1Y3QgY2FsbG91dCBzY19jYWxsb3V0OworfTsKKworc3RhdGljIHVpbnQzMl90IGJjbXJu Z19yZWFkKHN0cnVjdCBiY21ybmdfc29mdGMqIHNjKQoreworCXJldHVybiBSRUFEKHNjLCBSTkdf UkVHX0RBVEEpOworfQorCisjZGVmaW5lIFJOR19SRUFEX1NJWkUgNAorCitzdGF0aWMgdm9pZCBi Y21ybmdfaGFydmVzdChzdHJ1Y3Qgcm5kdGVzdF9zdGF0ZSAqc3RhdGUsIHZvaWQgKmJ1ZiwgdV9p bnQgY291bnQpCit7CisJcmFuZG9tX2hhcnZlc3RfcXVldWUoYnVmLCBjb3VudCwKKwkJY291bnQg KiA4IC8gMiwgUkFORE9NX1BVUkVfQkNNUk5HKTsKK30KKworc3RhdGljIHZvaWQgYmNtcm5nX2Rv X3JuZyh2b2lkKiBhcmcpCit7CisJc3RydWN0IGJjbXJuZ19zb2Z0Yyogc2MgPSBhcmc7CisJdWlu dDMyX3QgZW50cm9weVtSTkdfUkVBRF9TSVpFXTsKKwlpbnQgaTsKKworCWZvciAoaSA9IDA7IGkg PCBSTkdfUkVBRF9TSVpFOyBpKyspIHsKKwkJZW50cm9weVtpXSA9IGJjbXJuZ19yZWFkKHNjKTsK KwkJaWYgKDAgPT0gUkVBRChzYywgUk5HX1JFR19TVEFUVVMpID4+IDI0KSB7CisJCQlpKys7CisJ CQlicmVhazsKKwkJfQorCX0KKworCShzYy0+c2NfaGFydmVzdCkoc2MtPnNjX3JuZHRlc3QsIGVu dHJvcHksIHNpemVvZihlbnRyb3B5WzBdKSAqIGkpOworCisJY2FsbG91dF9yZXNldCgmc2MtPnNj X2NhbGxvdXQsIGh6ICogMSwgYmNtcm5nX2RvX3JuZywgc2MpOworfQorCisKK3N0YXRpYyBpbnQK K2JjbXJuZ19wcm9iZShkZXZpY2VfdCBkZXYpCit7CisKKwlpZiAoIW9md19idXNfc3RhdHVzX29r YXkoZGV2KSkKKwkJcmV0dXJuIChFTlhJTyk7CisKKwlpZiAob2Z3X2J1c19pc19jb21wYXRpYmxl KGRldiwgImJyb2FkY29tLGJjbTI4MzUtcm5nIikpIHsKKwkJZGV2aWNlX3NldF9kZXNjKGRldiwg IkJDTTI3MDgvMjgzNSByYW5kb20gbnVtYmVyIGdlbmVyYXRvciIpOworCQlyZXR1cm4gKEJVU19Q Uk9CRV9ERUZBVUxUKTsKKwl9CisKKwlyZXR1cm4gKEVOWElPKTsKK30KKworc3RhdGljIGludAor YmNtcm5nX2F0dGFjaChkZXZpY2VfdCBkZXYpCit7CisJc3RydWN0IGJjbXJuZ19zb2Z0YyAqc2M7 CisJaW50IHJpZDsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXNjLT5kZXYgPSBk ZXY7CisKKwlyaWQgPSAwOworCXNjLT5yZXMgPSBidXNfYWxsb2NfcmVzb3VyY2VfYW55KGRldiwg U1lTX1JFU19NRU1PUlksICZyaWQsIFJGX0FDVElWRSk7CisJaWYgKHNjLT5yZXMgPT0gTlVMTCkg eworCQlkZXZpY2VfcHJpbnRmKGRldiwgImNvdWxkIG5vdCBhbGxvY2F0ZSBtZW1vcnkgcmVzb3Vy Y2VcbiIpOworCQlyZXR1cm4gKEVOWElPKTsKKwl9CisKKwlzYy0+YnN0ID0gcm1hbl9nZXRfYnVz dGFnKHNjLT5yZXMpOworCXNjLT5ic2ggPSBybWFuX2dldF9idXNoYW5kbGUoc2MtPnJlcyk7CisK KwkvKiBlbmFibGUgYW5kIHdhcm4gdXAgKi8KKwlXUklURShzYywgUk5HX1JFR19TVEFUVVMsIDB4 NDAwMDApOworCVdSSVRFKHNjLCBSTkdfUkVHX0NUUkwsIDB4MDEpOworCisjaWZkZWYgQkNNUk5H X1JORFRFU1QKKwlzYy0+c2Nfcm5kdGVzdCA9IHJuZHRlc3RfYXR0YWNoKHNjLT5kZXYpOworCWlm IChzYy0+c2Nfcm5kdGVzdCkgeworCQlwcmludGYoIlJORFRFU1QgQVRUQUNIRUQhXG4iKTsKKwkJ c2MtPnNjX2hhcnZlc3QgPSBybmR0ZXN0X2hhcnZlc3Q7CisJfSBlbHNlIHsKKwkJcHJpbnRmKCJO TyBSTkRURVNUIEFWQUlMQUJMRSFcbiIpOworCQlzYy0+c2NfaGFydmVzdCA9IGJjbXJuZ19oYXJ2 ZXN0OworCX0KKyNlbHNlCisJc2MtPnNjX2hhcnZlc3QgPSBiY21ybmdfaGFydmVzdDsKKyNlbmRp ZgorCS8qIGluaXQgY2FsbG91dCAqLworCWNhbGxvdXRfaW5pdCgmc2MtPnNjX2NhbGxvdXQsIDEp OworCWNhbGxvdXRfcmVzZXQoJnNjLT5zY19jYWxsb3V0LCBoeiAqIDEsIGJjbXJuZ19kb19ybmcs IHNjKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2JjbXJuZ19kZXRhY2goZGV2 aWNlX3QgZGV2KQoreworCXN0cnVjdCBiY21ybmdfc29mdGMgKnNjOworCisJc2MgPSBkZXZpY2Vf Z2V0X3NvZnRjKGRldik7CisJY2FsbG91dF9zdG9wKCZzYy0+c2NfY2FsbG91dCk7CisjaWZkZWYg QkNNUk5HX1JORFRFU1QKKwlybmR0ZXN0X2RldGFjaChzYy0+c2Nfcm5kdGVzdCk7CisjZW5kaWYK KwlidXNfcmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfTUVNT1JZLCBybWFuX2dldF9yaWQo c2MtPnJlcyksCisJCQlzYy0+cmVzKTsKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGRldmljZV9t ZXRob2RfdCBiY21ybmdfbWV0aG9kc1tdID0geworCURFVk1FVEhPRChkZXZpY2VfcHJvYmUsIGJj bXJuZ19wcm9iZSksCisJREVWTUVUSE9EKGRldmljZV9hdHRhY2gsIGJjbXJuZ19hdHRhY2gpLAor CURFVk1FVEhPRChkZXZpY2VfZGV0YWNoLCBiY21ybmdfZGV0YWNoKSwKKworCURFVk1FVEhPRF9F TkQKK307CisKK3N0YXRpYyBkcml2ZXJfdCBiY21ybmdfZHJpdmVyID0geworCSJiY21ybmciLAor CWJjbXJuZ19tZXRob2RzLAorCXNpemVvZihzdHJ1Y3QgYmNtcm5nX3NvZnRjKSwKK307CisKK3N0 YXRpYyBkZXZjbGFzc190IGJjbXJuZ19kZXZjbGFzczsKKworRFJJVkVSX01PRFVMRShiY21ybmcs IHNpbXBsZWJ1cywgYmNtcm5nX2RyaXZlciwgYmNtcm5nX2RldmNsYXNzLCAwLCAwKTsKKyNpZmRl ZiBCQ01STkdfUk5EVEVTVAorTU9EVUxFX0RFUEVORChiY21ybmcsIHJuZHRlc3QsIDEsIDEsIDEp OworI2VuZGlmCgpQcm9wZXJ0eSBjaGFuZ2VzIG9uOiBhcm0vYnJvYWRjb20vYmNtMjgzNS9iY20y ODM1X3JuZy5jCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KQWRkZWQ6IHN2bjplb2wtc3R5bGUKIyMgLTAsMCArMSAjIwor bmF0aXZlClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKQWRkZWQ6IHN2bjpleGVjdXRh YmxlCiMjIC0wLDAgKzEgIyMKKyoKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRl ZDogc3ZuOmtleXdvcmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0 IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOm1pbWUtdHlwZQojIyAtMCwwICsxICMjCit0ZXh0 L3BsYWluClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKSW5kZXg6IGFybS9icm9hZGNv bS9iY20yODM1L2ZpbGVzLmJjbTI4M3gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYXJtL2Jyb2FkY29tL2JjbTI4 MzUvZmlsZXMuYmNtMjgzeAkocmV2aXNpb24gMzAyMzA2KQorKysgYXJtL2Jyb2FkY29tL2JjbTI4 MzUvZmlsZXMuYmNtMjgzeAkod29ya2luZyBjb3B5KQpAQCAtMTAsNiArMTAsNyBAQAogYXJtL2Jy b2FkY29tL2JjbTI4MzUvYmNtMjgzNV9pbnRyLmMJCXN0YW5kYXJkCiBhcm0vYnJvYWRjb20vYmNt MjgzNS9iY20yODM1X21hY2hkZXAuYwkJc3RhbmRhcmQKIGFybS9icm9hZGNvbS9iY20yODM1L2Jj bTI4MzVfbWJveC5jCQlzdGFuZGFyZAorYXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV9ybmcu YwkgICAgCXN0YW5kYXJkCiBhcm0vYnJvYWRjb20vYmNtMjgzNS9iY20yODM1X3NkaGNpLmMJCW9w dGlvbmFsIHNkaGNpCiBhcm0vYnJvYWRjb20vYmNtMjgzNS9iY20yODM1X3NwaS5jCQlvcHRpb25h bCBiY20yODM1X3NwaQogYXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV92Y2lvLmMJCXN0YW5k YXJkCkluZGV4OiBhcm0vY29uZi9SUEkyCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGFybS9jb25mL1JQSTIJKHJl dmlzaW9uIDMwMjMwNikKKysrIGFybS9jb25mL1JQSTIJKHdvcmtpbmcgY29weSkKQEAgLTU1LDYg KzU1LDggQEAKIAogb3B0aW9ucyAJUk9PVERFVk5BTUU9XCJ1ZnM6bW1jc2QwczJcIgogCitkZXZp Y2UJCXJuZHRlc3QKK29wdGlvbnMJCUJDTVJOR19STkRURVNUCiAjIEFSTSBHZW5lcmljIFRpbWVy CiBkZXZpY2UJCWdlbmVyaWNfdGltZXIKIApJbmRleDogYm9vdC9mZHQvZHRzL2FybS9iY20yODM1 LmR0c2kKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gYm9vdC9mZHQvZHRzL2FybS9iY20yODM1LmR0c2kJKHJldmlz aW9uIDMwMjMwNikKKysrIGJvb3QvZmR0L2R0cy9hcm0vYmNtMjgzNS5kdHNpCSh3b3JraW5nIGNv cHkpCkBAIC0xMDEsNiArMTAxLDEyIEBACiAJCQkgKi8KIAkJfTsKIAorCQlybmcgeworCQkJY29t cGF0aWJsZSA9ICJicm9hZGNvbSxiY20yODM1LXJuZyIsCisJCQkJICAgICAiYnJvYWRjb20sYmNt MjcwOC1ybmciOworCQkJcmVnID0gPDB4MTA0MDAwIDB4MTA+OworCQl9OworCiAJCXRpbWVyIHsK IAkJCWNvbXBhdGlibGUgPSAiYnJvYWRjb20sYmNtMjgzNS1zeXN0ZW0tdGltZXIiLCAKIAkJCQkg ICAgICJicm9hZGNvbSxiY20yNzA4LXN5c3RlbS10aW1lciI7CkluZGV4OiBib290L2ZkdC9kdHMv YXJtL2JjbTI4MzYuZHRzaQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBib290L2ZkdC9kdHMvYXJtL2JjbTI4MzYu ZHRzaQkocmV2aXNpb24gMzAyMzA2KQorKysgYm9vdC9mZHQvZHRzL2FybS9iY20yODM2LmR0c2kJ KHdvcmtpbmcgY29weSkKQEAgLTExMiw2ICsxMTIsMTIgQEAKIAkJCSAqLwogCQl9OwogCisJCXJu ZyB7CisJCQljb21wYXRpYmxlID0gImJyb2FkY29tLGJjbTI4MzUtcm5nIiwKKwkJCQkgICAgICJi cm9hZGNvbSxiY20yNzA4LXJuZyI7CisJCQlyZWcgPSA8MHgxMDQwMDAgMHgxMD47CisJCX07CisK IAkJd2F0Y2hkb2cwIHsKIAkJCWNvbXBhdGlibGUgPSAiYnJvYWRjb20sYmNtMjgzNS13ZHQiLAog CQkJCSAgICAgImJyb2FkY29tLGJjbTI3MDgtd2R0IjsKSW5kZXg6IGNvbmYvb3B0aW9ucwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBjb25mL29wdGlvbnMJKHJldmlzaW9uIDMwMjMwNikKKysrIGNvbmYvb3B0aW9u cwkod29ya2luZyBjb3B5KQpAQCAtNzU2LDYgKzc1Niw5IEBACiBTQUZFX05PX1JORwkJb3B0X3Nh ZmUuaAogU0FGRV9STkRURVNUCQlvcHRfc2FmZS5oCiAKKyMgb3B0aW9ucyBmb3IgYmNtcm5nIGRy aXZlcgorQkNNUk5HX1JORFRFU1QJCW9wdF9iY21ybmcuaAorCiAjIHN5c2NvbnMvdnQgb3B0aW9u cwogTUFYQ09OUwkJCW9wdF9zeXNjb25zLmgKIFNDX0FMVF9NT1VTRV9JTUFHRQlvcHRfc3lzY29u cy5oCkluZGV4OiBkZXYvcm5kdGVzdC9ybmR0ZXN0LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZGV2L3JuZHRl c3Qvcm5kdGVzdC5jCShyZXZpc2lvbiAzMDIzMDYpCisrKyBkZXYvcm5kdGVzdC9ybmR0ZXN0LmMJ KHdvcmtpbmcgY29weSkKQEAgLTE2OSw4ICsxNjksMTAgQEAKIAogCWlmIChybmR0ZXN0X3ZlcmJv c2UgPT0gMCkKIAkJcmV0dXJuOworI2lmIDAgLyogc2VlIHdoYXQgc3VjY2VlZGVkIHJ1biB3aWxs IHJlcG9ydCAqLwogCWlmICghZmFpbHVyZSAmJiBybmR0ZXN0X3ZlcmJvc2UgPT0gMSkJLyogZG9u J3QgcmVwb3J0IHN1Y2Nlc3NlcyAqLwogCQlyZXR1cm47CisjZW5kaWYKIAl2YV9zdGFydChhcCwg Zm10KTsKIAl2c25wcmludGYoYnVmLCBzaXplb2YgKGJ1ZiksIGZtdCwgYXApOwogCXZhX2VuZChh cCk7CkluZGV4OiBzeXMvcmFuZG9tLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3JhbmRvbS5oCShyZXZp c2lvbiAzMDIzMDYpCisrKyBzeXMvcmFuZG9tLmgJKHdvcmtpbmcgY29weSkKQEAgLTkwLDYgKzkw LDcgQEAKIAlSQU5ET01fUFVSRV9ORUhFTUlBSCwKIAlSQU5ET01fUFVSRV9STkRURVNULAogCVJB TkRPTV9QVVJFX1ZJUlRJTywKKwlSQU5ET01fUFVSRV9CQ01STkcsCiAJRU5UUk9QWVNPVVJDRQog fTsKIAo= --94eb2c07ae600b6c250537a51ddc-- From owner-freebsd-arm@freebsd.org Fri Jul 15 13:36:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 400D5B98F17 for ; Fri, 15 Jul 2016 13:36:34 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1646A1310 for ; Fri, 15 Jul 2016 13:36:33 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 71E1F85F; Fri, 15 Jul 2016 09:36:27 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Paul Mather In-Reply-To: Date: Fri, 15 Jul 2016 09:36:26 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 13:36:34 -0000 On Jul 14, 2016, at 11:36 PM, Karl Denninger wrote: > On 7/14/2016 13:27, Karl Denninger wrote: >> On 7/14/2016 12:55, Ian Lepore wrote: >> No there wasn't. It was a blank (brand new) card the first time = around; >> it had a MSDOS filesystem on it (as do all new cards) but *no* >> BSD-specific geom anything on it. >>> To reliably create a new layout regardless of what may be present >>> already on the media, you have two choices: >>>=20 >>> 1 - dd zeroes to the entire device >>> 2 - use the "no commit" feature of gpart >> Actually in the case at hand #1 isn't impractical since I really only >> care about the first 100MB or so being zeroed. The reason is that my >> boot block (the MSDOS fs) is ~50Mb and the label is obviously next, = so >> if we zero the first 100MB we're fine. >>=20 >> And in fact that does work. >>> When you pass no '-f ' to a gpart command, it automatically = adds >>> the "-f C" (commit) flag behind your back. There is no "don't = commit" >>> flag, so (this is surrealistically crazy...) what you're supposed to = do >>> is pass an invalid flag, which it won't complain about, in order to >>> prevent it from automatically adding that 'C' flag you didn't even >>> realize existed. (This is where *I* curse whoever coded this mess.) >>>=20 >>> When you don't commit, the changes take place in a sort of 'virtual >>> workspace' and nothing on the physical disk changes until you do a >>> "gpart commit" (or "gpart undo" to discard the changes). Making all >>> this much-less-cool that it's sounding right now, there is no = automatic >>> recursion for commit and undo... if you create a bunch of nested = stuff >>> (a slice, a geom within that slice, parititions within that geom), = then >>> you have to commit all the pending new geoms *in reverse order of = how >>> they were created*. >>>=20 >>> So, using da0 (since it's shorter to type), the sequence goes like: >>>=20 >>> gpart destroy -f x -F da0 >>> gpart create -f x -s MBR da0 >>> gpart add -f x -t \!12 -s 64M -a 4M da0 >>> gpart add -f x -t freebsd -a 4M da0 >>> gpart destroy -f x -F da0s2 >>> gpart create -f x -s BSD da0s2 >>> gpart add -f x -t freebsd-ufs da0s2 >>> gpart commit da0s2 >>> gpart commit da0 >>> newfs_msdos /dev/da0s1 >>> newfs -U /dev/da0s2a >>>=20 >>> And that reliably creates a fresh rpi-style layout regardless of = what >>> was on the media before you started. >> Ok, I will try this, BUT I suspect it's still screwed (blind) because >> when I zeroed the front of the disk I got a "correct" partition = layout >> but after populating it what I get still hangs after it mounts root = in >> the same place. The way to prevent the alignment issue from coming = up >> is to specify a "-b" switch on the "add", giving you a block offset.=20= >> "-b 64" is sufficient; now if the system tries to "taste" da0s2 it = will >> fail (as it does for the card that is running) but "tasting" da0s2a >> succeeds. >>> Now, to address the question of the filesystem existing at da0s2 = versus >>> da0s2a, the difference is alignment. Making things even more >>> confusing, alignment (if you don't specify it) sometimes changes = based >>> on the type and brand of usb sdcard reader you're using and the fake >>> geometry values it reports to the system. (A USB reader almost = always >>> reports different fake geometry than a native sd slot would on a >>> machine with non-USB based sd support.) >> Yes, I understand that; if the alignment matches thus the "a" = partition >> starts at offset zero then you can actually reference that (although >> length might be wrong) with the base device. After all, what it = really >> does is look at the blocks to see if the magic number is good, and if = so >> it tries to read and process it. >>=20 >> But this doesn't explain why, after getting a layout that's correct = (by >> writing zeros to the front of the card first, so anything that = "might" >> be there isn't) and copying all the file structure over (which = facially >> not only appears to be correct but the loader finds and loads the >> kernel, AND the root filesystem mounts!) the system hangs, apparently >> just before init gets started. >>=20 >> If init can't be found you should get a complaint (been there, done >> that) on the console but there is no complaint of any sort. >>=20 >> I've gotten through the bad structure issue on the SD card, and am = now >> left with "why does it hang on boot -- with no error or other = indication >> of what the problem is" after the kernel loads *and* the root = filesystem >> mounts? >>=20 > Found it. >=20 > Apparently the current code *requires* the label be set on the msdos > partition. If it's not then not only does it not mount (which = shouldn't > matter post-boot as the loader is supposed to pass the dtb file, it is > specified in the config file without any sort of path prefix, and thus > once the kernel has loaded it should not matter if the dos partition = if > actually mounted or not) *but* the boot process hangs without any > indication of why! >=20 > So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} >=20 > If the "-L" is missing you're hosed; the system facially appears to be > just fine but while the loader comes up and so does the kernel, it = hangs > without ever proceeding -- and without any sort of error message > indicating that it is unable to mount something it needs. You have to do that because the device entry in the stock /etc/fstab is = /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part indicates it's using = ms-dos labels. In other words, this is just the same sort of failure = you were getting when you weren't labelling the UFS partition as = "rootfs". Labelling the file system properly "fixes" the issue, as you = would expect. It's a misnomer to say the code "requires" labels. It's just that's the = way the distribution images are currently set up. I have an older Pi = that predates the current distribution images that just uses = /dev/mmcsd0... device names in /etc/fstab. Both approaches work fine. = You just need to make sure the devices you specify in /etc/fstab will = actually exist when it comes time to mount the corresponding file = system. If you stop using labels in your /etc/fstab then you won't have problems = when those labels are missing. If the labels are missing, the = /dev/{msdosfs,ufs} devices will not be present and the system will drop = to single-user mode because none-late, non-noauto file systems can't be = accessed via their device nodes when attempting to mount them. When = that happens and you don't have a serial console enabled then you have = problems remediating the situation. If a file system is not needed to mount as part of booting (as you = suggest for /boot/msdos) then you should probably flag it with the = "noauto" option in /etc/fstab or remove it from /etc/fstab entirely. I think the problem you were having is not copying all the required = attributes of the file systems in question when cloning your SD cards, = given your /etc/fstab setup. It sounds like you've fixed that, now. Cheers, Paul. >=20 > I can clone cards now. >=20 > --=20 > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Fri Jul 15 13:44:41 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BA43B9924F for ; Fri, 15 Jul 2016 13:44:41 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 AE4B418D9 for ; Fri, 15 Jul 2016 13:44:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 5529844C77A for ; Fri, 15 Jul 2016 08:44:39 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> To: freebsd-arm@freebsd.org From: Karl Denninger Message-ID: <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> Date: Fri, 15 Jul 2016 08:44:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050304070703030100050200" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 13:44:41 -0000 This is a cryptographically signed message in MIME format. --------------ms050304070703030100050200 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/15/2016 08:36, Paul Mather wrote: > On Jul 14, 2016, at 11:36 PM, Karl Denninger wrote= : > >> Found it. >> >> Apparently the current code *requires* the label be set on the msdos >> partition. If it's not then not only does it not mount (which shouldn= 't >> matter post-boot as the loader is supposed to pass the dtb file, it is= >> specified in the config file without any sort of path prefix, and thus= >> once the kernel has loaded it should not matter if the dos partition i= f >> actually mounted or not) *but* the boot process hangs without any >> indication of why! >> >> So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} >> >> If the "-L" is missing you're hosed; the system facially appears to be= >> just fine but while the loader comes up and so does the kernel, it han= gs >> without ever proceeding -- and without any sort of error message >> indicating that it is unable to mount something it needs. > > You have to do that because the device entry in the stock /etc/fstab is= /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part indicates it's using ms-d= os labels. In other words, this is just the same sort of failure you wer= e getting when you weren't labelling the UFS partition as "rootfs". Labe= lling the file system properly "fixes" the issue, as you would expect. > > It's a misnomer to say the code "requires" labels. It's just that's th= e way the distribution images are currently set up. I have an older Pi t= hat predates the current distribution images that just uses /dev/mmcsd0..= =2E device names in /etc/fstab. Both approaches work fine. You just nee= d to make sure the devices you specify in /etc/fstab will actually exist = when it comes time to mount the corresponding file system. Except that if the root filesystem doesn't mount you get an error, and thus you can figure out what's going on. What excuse is there for not printing an error message if a mount fails, and if something in /etc/fstab fails to mount what's with hanging the machine? I've had disks be unavailable before on Intel architecture machines (it happens when disks fail) and the result is an error on the failure to mount but, unless it's the root volume, the system still comes up. > If you stop using labels in your /etc/fstab then you won't have problem= s when those labels are missing. If the labels are missing, the /dev/{ms= dosfs,ufs} devices will not be present and the system will drop to single= -user mode because none-late, non-noauto file systems can't be accessed v= ia their device nodes when attempting to mount them. When that happens a= nd you don't have a serial console enabled then you have problems remedia= ting the situation. > > If a file system is not needed to mount as part of booting (as you sugg= est for /boot/msdos) then you should probably flag it with the "noauto" o= ption in /etc/fstab or remove it from /etc/fstab entirely. > > I think the problem you were having is not copying all the required att= ributes of the file systems in question when cloning your SD cards, given= your /etc/fstab setup. It sounds like you've fixed that, now. Again, if it dropped to single user mode *and said it was doing so* or if there was an error message on the console when the filesystem failed to mount I would have found this in a reasonable period of time. It wasn't that rough to do so with the ufs label once I knew the filesystem was failing to mount, which was discernible from the console output. Not printing an error when things error out is rude at best, and when that error is going to prevent the system from coming up this darn well ought to show up where one with a monitor plugged in can see it, eh? There was literally no indication at all as to what was going on and since gpart does not show filesystem labels for *either* BSD labeled slices OR msdos figuring out what was different between the two proved to be a bit troublesome. IMHO at least the failure to display an error message in this circumstance ought to be corrected. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050304070703030100050200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxMzQ0MzZaME8GCSqGSIb3DQEJBDFCBEBk 0pgWHac/bjWAGJJa66I5NoXGL1KyGxfVJasqFsMEbaxJ+G/X6gA/ELUBXqD4h8wJgUsOHmLP v/16VXg2lnGTMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAO0Qhbh8e 3w094MDSYErDQEiNrcAvmtbmfGSFXTpfbLtvRDDLftgXdt8hi8TON/RCmNOaYFg0dvJok+2Y lC/ZSBEc8fW+ww22GGJTirG8iOJv9Fc825Bj0EztVb6g/2bnahHnSEZPGqWhYp1B7PZTQGCk DZ0/YpwisdEgwA1kTx2QI4dtw+Ow1YJ6jVvu15LSEIQb+47AVTGxqqEHsGQGYEOUxkuNDo1k GTR1pWjxrUcU0CgysTKwrRwFCy2EiLu7r7C8MVClXdeTMNPYQck8Bky0tU7P/R0XI5yV6H+6 HHQFlnWBp2JQa33bLSjoo5oO4IIUdMbDNVZmcd5vYdZE0PyQrn79Hyum6a3BrTssF0cojVa/ /7s/kz2dWh9Iad3l/bGLxJ/3lfcxL0DMWk9BuqNzdhwGfiHDx/EycdwBG90EuY0kGnImcUnb C4Gwtwmeo8HEqcsiHtg4BbL+P8h7yl3rKA33E2kBMejk/OUbzDhnvt8Qyl3qJz3yBmuMOKqG FdoW2YVug/JuJOxQixA64Ilfvt9Tm7PN6NE3j6djpXSO3jK3Q7HMJcXPE6gbiM8FsqVYLQHE nnLwYA4aL3FicN9xWyW0RWSYnRyeb66no86DIYjJnjzDWhMfqleIdUHmyLTCbyX5AU2NZAT0 H76mtq20rTpZGP3eA57eSPyCopQAAAAAAAA= --------------ms050304070703030100050200-- From owner-freebsd-arm@freebsd.org Fri Jul 15 14:22:28 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97035B99E79 for ; Fri, 15 Jul 2016 14:22:28 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E9CD1211 for ; Fri, 15 Jul 2016 14:22:28 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id DF36E905; Fri, 15 Jul 2016 10:22:26 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Paul Mather In-Reply-To: <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> Date: Fri, 15 Jul 2016 10:22:26 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 14:22:28 -0000 On Jul 15, 2016, at 9:44 AM, Karl Denninger wrote: > On 7/15/2016 08:36, Paul Mather wrote: >> On Jul 14, 2016, at 11:36 PM, Karl Denninger = wrote: >>=20 >>> Found it. >>>=20 >>> Apparently the current code *requires* the label be set on the msdos >>> partition. If it's not then not only does it not mount (which = shouldn't >>> matter post-boot as the loader is supposed to pass the dtb file, it = is >>> specified in the config file without any sort of path prefix, and = thus >>> once the kernel has loaded it should not matter if the dos partition = if >>> actually mounted or not) *but* the boot process hangs without any >>> indication of why! >>>=20 >>> So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} >>>=20 >>> If the "-L" is missing you're hosed; the system facially appears to = be >>> just fine but while the loader comes up and so does the kernel, it = hangs >>> without ever proceeding -- and without any sort of error message >>> indicating that it is unable to mount something it needs. >>=20 >> You have to do that because the device entry in the stock /etc/fstab = is /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part indicates it's using = ms-dos labels. In other words, this is just the same sort of failure = you were getting when you weren't labelling the UFS partition as = "rootfs". Labelling the file system properly "fixes" the issue, as you = would expect. >>=20 >> It's a misnomer to say the code "requires" labels. It's just that's = the way the distribution images are currently set up. I have an older = Pi that predates the current distribution images that just uses = /dev/mmcsd0... device names in /etc/fstab. Both approaches work fine. = You just need to make sure the devices you specify in /etc/fstab will = actually exist when it comes time to mount the corresponding file = system. > Except that if the root filesystem doesn't mount you get an error, and > thus you can figure out what's going on. What excuse is there for not > printing an error message if a mount fails, and if something in > /etc/fstab fails to mount what's with hanging the machine? I've had > disks be unavailable before on Intel architecture machines (it happens > when disks fail) and the result is an error on the failure to mount = but, > unless it's the root volume, the system still comes up. Are you sure you don't get an error? When I forgot to label rootfs = recently when I cloned an SD card I got an error displayed on the serial = console. I didn't get an error on the HDMI screen console. As I've mentioned before directly, FreeBSD/arm acts like = console=3D"comconsole,vidconsole" is in effect. This means that during = /etc/rc boot processing, you'll only get output on comconsole (except = for kernel messages, which seem to go to both). That's been my = experience in FreeBSD in general. I dimly recall folks on here saying U-Boot doesn't currently = enable/support USB keyboards, so there's not really much you can do to = fix it interactively if you fail to boot the OS and hence enable USB = keyboard support via FreeBSD. That's not a problem if you use a serial = console, which is supported by U-Boot. I'm not sure comparisons with Intel architecture machines is entirely = appropriate as they use a different boot environment/mechanism. Still, = I stand by the fact that I've always got an error message on the serial = console when disks on my FreeBSD/arm system have failed to mount at = boot. (It used to happen regularly with an external USB drive I had = that took a long time to probe, and I ended up having to put a = kern.cam.boot_delay in /boot/loader.conf to avoid the system dropping = into single-user mode when doing a reboot.) >=20 >> If you stop using labels in your /etc/fstab then you won't have = problems when those labels are missing. If the labels are missing, the = /dev/{msdosfs,ufs} devices will not be present and the system will drop = to single-user mode because none-late, non-noauto file systems can't be = accessed via their device nodes when attempting to mount them. When = that happens and you don't have a serial console enabled then you have = problems remediating the situation. >>=20 >> If a file system is not needed to mount as part of booting (as you = suggest for /boot/msdos) then you should probably flag it with the = "noauto" option in /etc/fstab or remove it from /etc/fstab entirely. >>=20 >> I think the problem you were having is not copying all the required = attributes of the file systems in question when cloning your SD cards, = given your /etc/fstab setup. It sounds like you've fixed that, now. > Again, if it dropped to single user mode *and said it was doing so* or > if there was an error message on the console when the filesystem = failed > to mount I would have found this in a reasonable period of time. It > wasn't that rough to do so with the ufs label once I knew the = filesystem > was failing to mount, which was discernible from the console output. >=20 > Not printing an error when things error out is rude at best, and when > that error is going to prevent the system from coming up this darn = well > ought to show up where one with a monitor plugged in can see it, eh? >=20 > There was literally no indication at all as to what was going on and > since gpart does not show filesystem labels for *either* BSD labeled > slices OR msdos figuring out what was different between the two proved > to be a bit troublesome. IMHO at least the failure to display an = error > message in this circumstance ought to be corrected. See above re: serial console vs. video console. As for the labels, these are file system labels and not partition = labels. The big clue is in the device name in /etc/fstab. (The "-l" = option to "gpart show" will only show labels "[f]or partitioning schemes = that support partition labels". That's reasonable, IMHO, as partitions = are not the same as file systems and gpart is concerned with = partitions.) In my experience, complaints about not being able to = access /dev/ufs/something means you forgot to label a UFS file system as = "something" when you made it. :-) Cheers, Paul.= From owner-freebsd-arm@freebsd.org Fri Jul 15 14:34:15 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76A49B9A0BC for ; Fri, 15 Jul 2016 14:34:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C8A318D2 for ; Fri, 15 Jul 2016 14:34:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u6FEYFLh023625 for ; Fri, 15 Jul 2016 14:34:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 211143] Add "failok" to the /etc/fstab file entry for the DOS filesystem on uboot-using ARM devices. Date: Fri, 15 Jul 2016 14:34:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-BETA1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: karl@denninger.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 14:34:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211143 Bug ID: 211143 Summary: Add "failok" to the /etc/fstab file entry for the DOS filesystem on uboot-using ARM devices. Product: Base System Version: 11.0-BETA1 Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: karl@denninger.net On ARM systems where uboot is used, the MSDOS filesystem is required only f= or the actual boot. Once the kernel is loaded the filesystem can be mounted, = but doesn't *have* to be mounted. The default /etc/fstab entry, however, does two things that are troublesome= .=20 First, it uses /dev/ufs and /dev/msdosfs prefixes for the filesystem lookup= s, which means that those filesystems must be labeled. However, gpart cannot display those labels since they are in the msdos and BSD-labeled components= of same, respectively, and due to the Raspberry PIs (and other similar ARM systems) boot code demands an MBR formatted boot device structure. That is defensible, however, given the idea that we might not know where th= e SD card would attach on a given board (e.g. on which device name.) What is far less-defensible, however, is not specifying "failok" for the MSDOS partition since having it mounted post-boot is not necessary. If the label is missing on the dos partition the system will boot, the kern= el will load, but then it hangs *silently* from the perspective of a video con= sole without any error message being displayed. This problem comes about as a consequence of single-user mode not coming up on the video console (which a= lso is broken, IMHO) *and* the lack of the error on the mount resulting in a console display. In short arguably the system *should* be able to come up in single user mod= e on both the video and serial console on these machines, yet that may be too mu= ch of an ask. The easy fix for the instant problem, however, is to add "failok" to the ms= dos filesystem line in the default /etc/fstab file since the DOS filesystem does not have to be mounted for the system to come up once uboot had loaded. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Jul 15 14:44:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33C58B9A575 for ; Fri, 15 Jul 2016 14:44:29 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 E79A51E83 for ; Fri, 15 Jul 2016 14:44:28 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id A2EA144CA21 for ; Fri, 15 Jul 2016 09:44:25 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> To: freebsd-arm From: Karl Denninger Message-ID: Date: Fri, 15 Jul 2016 09:44:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050309030404030506070706" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 14:44:29 -0000 This is a cryptographically signed message in MIME format. --------------ms050309030404030506070706 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/15/2016 09:22, Paul Mather wrote: > On Jul 15, 2016, at 9:44 AM, Karl Denninger wrote:= > >> On 7/15/2016 08:36, Paul Mather wrote: >>> On Jul 14, 2016, at 11:36 PM, Karl Denninger wro= te: >>> >>>> Found it. >>>> >>>> Apparently the current code *requires* the label be set on the msdos= >>>> partition. If it's not then not only does it not mount (which shoul= dn't >>>> matter post-boot as the loader is supposed to pass the dtb file, it = is >>>> specified in the config file without any sort of path prefix, and th= us >>>> once the kernel has loaded it should not matter if the dos partition= if >>>> actually mounted or not) *but* the boot process hangs without any >>>> indication of why! >>>> >>>> So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} >>>> >>>> If the "-L" is missing you're hosed; the system facially appears to = be >>>> just fine but while the loader comes up and so does the kernel, it h= angs >>>> without ever proceeding -- and without any sort of error message >>>> indicating that it is unable to mount something it needs. >>> You have to do that because the device entry in the stock /etc/fstab = is /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part indicates it's using ms= -dos labels. In other words, this is just the same sort of failure you w= ere getting when you weren't labelling the UFS partition as "rootfs". La= belling the file system properly "fixes" the issue, as you would expect. >>> >>> It's a misnomer to say the code "requires" labels. It's just that's = the way the distribution images are currently set up. I have an older Pi= that predates the current distribution images that just uses /dev/mmcsd0= =2E.. device names in /etc/fstab. Both approaches work fine. You just n= eed to make sure the devices you specify in /etc/fstab will actually exis= t when it comes time to mount the corresponding file system. >> Except that if the root filesystem doesn't mount you get an error, and= >> thus you can figure out what's going on. What excuse is there for not= >> printing an error message if a mount fails, and if something in >> /etc/fstab fails to mount what's with hanging the machine? I've had >> disks be unavailable before on Intel architecture machines (it happens= >> when disks fail) and the result is an error on the failure to mount bu= t, >> unless it's the root volume, the system still comes up. > > Are you sure you don't get an error? When I forgot to label rootfs rec= ently when I cloned an SD card I got an error displayed on the serial con= sole. I didn't get an error on the HDMI screen console. You get an error if rootfs is not labelled on the HDMI screen (as root fails to mount.) There is *no* error on an HDMI screen if the msdosfs is not labeled. > As I've mentioned before directly, FreeBSD/arm acts like console=3D"com= console,vidconsole" is in effect. This means that during /etc/rc boot pr= ocessing, you'll only get output on comconsole (except for kernel message= s, which seem to go to both). That's been my experience in FreeBSD in ge= neral. > > I dimly recall folks on here saying U-Boot doesn't currently enable/sup= port USB keyboards, so there's not really much you can do to fix it inter= actively if you fail to boot the OS and hence enable USB keyboard support= via FreeBSD. That's not a problem if you use a serial console, which is= supported by U-Boot. Well, that's not true if the kernel is loaded. Once the kernel loads a usb keyboard works. > > I'm not sure comparisons with Intel architecture machines is entirely a= ppropriate as they use a different boot environment/mechanism. Still, I = stand by the fact that I've always got an error message on the serial con= sole when disks on my FreeBSD/arm system have failed to mount at boot. (= It used to happen regularly with an external USB drive I had that took a = long time to probe, and I ended up having to put a kern.cam.boot_delay in= /boot/loader.conf to avoid the system dropping into single-user mode whe= n doing a reboot.) > > >>> If you stop using labels in your /etc/fstab then you won't have probl= ems when those labels are missing. If the labels are missing, the /dev/{= msdosfs,ufs} devices will not be present and the system will drop to sing= le-user mode because none-late, non-noauto file systems can't be accessed= via their device nodes when attempting to mount them. When that happens= and you don't have a serial console enabled then you have problems remed= iating the situation. >>> >>> If a file system is not needed to mount as part of booting (as you su= ggest for /boot/msdos) then you should probably flag it with the "noauto"= option in /etc/fstab or remove it from /etc/fstab entirely. >>> >>> I think the problem you were having is not copying all the required a= ttributes of the file systems in question when cloning your SD cards, giv= en your /etc/fstab setup. It sounds like you've fixed that, now. >> Again, if it dropped to single user mode *and said it was doing so* or= >> if there was an error message on the console when the filesystem faile= d >> to mount I would have found this in a reasonable period of time. It >> wasn't that rough to do so with the ufs label once I knew the filesyst= em >> was failing to mount, which was discernible from the console output. >> >> Not printing an error when things error out is rude at best, and when >> that error is going to prevent the system from coming up this darn wel= l >> ought to show up where one with a monitor plugged in can see it, eh? >> >> There was literally no indication at all as to what was going on and >> since gpart does not show filesystem labels for *either* BSD labeled >> slices OR msdos figuring out what was different between the two proved= >> to be a bit troublesome. IMHO at least the failure to display an erro= r >> message in this circumstance ought to be corrected. > > See above re: serial console vs. video console. > > As for the labels, these are file system labels and not partition label= s. The big clue is in the device name in /etc/fstab. (The "-l" option t= o "gpart show" will only show labels "[f]or partitioning schemes that sup= port partition labels". That's reasonable, IMHO, as partitions are not t= he same as file systems and gpart is concerned with partitions.) In my e= xperience, complaints about not being able to access /dev/ufs/something m= eans you forgot to label a UFS file system as "something" when you made i= t. :-) > > Cheers, > > Paul. Understood, but the issue here is that there's no indication without a serial console that you have anything wrong -- the system appears to have simply hung. The quick fix is to put "failok" (or noauto) in the default /etc/fstab entry for the dos filesystem, since it is not necessary for that filesystem to be mounted at all on a running machine. If there is a policy reason to leave it accessible (and there's a fairly-clean argument that there is) then "failok" might be preferable to "noauto", but either way forcing a filesystem that is not necessary to be accessible or the system fails to come up and does not give any indication of same on what many users will have accessible to them is facially wrong. These devices are thought of as "appliances" by many and as such the model of USB keyboard + HDMI (e.g. TV or monitor) is entirely reasonable, and IMHO FreeBSD ought to, when possible, make that a viable option. It both is and can be provided the kernel loads, but the defaults in pre-built configurations right now preclude that. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050309030404030506070706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxNDQ0MjNaME8GCSqGSIb3DQEJBDFCBEAU BWw+e2UIci1jPGY5CcQURgT3a9qt26aoyPnMXmwf083eRtotXqguxULx6bKS473IysQtykVc RVUJgxs/Qe/aMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAsqk3ZkjH t5go36OFOsxX5TxkvwAD8Ycr3fPSdpwTaKl/RJWJ8zud6igigO1Lbifij/I0hkyGszWn+3aa 02YOmUAhBmXr2E138r51kHB/FtjznE6WU2Vx5TetUJgSVr8uqIus2xetvIeKHLqNQCojQA/s dOaWBqPByXco62eHLh/F204XXJate/0GJ2UTgVqFWFriy6Jj3okx7IHj3vARtKtbiMAWWIQG D6OW8wkc+GYQjlkpOu6SVWjFFsQ6aE4gMIM8c2+wqn1BI/N0ymWhUErrl1221bZkPIC7h1rx Yj46uQmcn4jrkIh+R8+nNvobdxwXt3/QA+vbO0QhqMMIVvU/FPfWLf7VWc3v+yZlpVxKTLH9 W7siFt9sJ6EnbXdopYufDTiRQOpoOe//7ilrH1wRcsWyv7CBCtGdpQGXCQg+yzoNDmrj8jXe HDcooHdihOKe5kpqfmbtvBAYjzZmDvADGp8GeIaPfOgFPh8yo4gvcxU833CG4uZHsfBMLiuL vkgHbu91MWomIdiCdcd7GeySmO5Sa0iRgr4S5oUGsN8Ojdc5G52g8rcv5z5kY3OHTISRfbjH /3yfYzLZAuDzyV41FqCoMsnRHpIzh45gvZB09gJPEXUESQAawbW5bfkz/JIQ53VnVKxr9qcw AEZqVcBuCk2wOqNru9NkRwDRqdgAAAAAAAA= --------------ms050309030404030506070706-- From owner-freebsd-arm@freebsd.org Fri Jul 15 14:53:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF447B9A701 for ; Fri, 15 Jul 2016 14:53:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD602132D for ; Fri, 15 Jul 2016 14:53:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id q83so106605261iod.1 for ; Fri, 15 Jul 2016 07:53:31 -0700 (PDT) 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:content-transfer-encoding; bh=huH/mNxjK+YnNLpFi8H0WB//O+q9s3l6Xm1guckOifk=; b=Bez2ftUdqTIKsCA4JQEE49cjfE54v6dgP470V2+mRvkQ1YiD9ptsu0dRHRZiy46z1l wPjLDzUwcG4DnQzzvGnmmqe1dv59FZHbEszZZacaBre0ygXFJ+qfUjUCvCezlQ4XQ6DP 04Aeb3NQ/FOiC6UgLoIx5XMTUQvoYXelpExf6WRYlAJ5PbssXmFDt4iLTiv9rFZoYen3 KMthgYEm0kn54r+3fNBEDf7Xb71B/GH9ipo23Oy8gs+2Z3pAUccUeDyMx5hWaU7FR4IX n9u7XGqnbUGgNH25a/l+5xPVdafnlHlqKir/Tu4ahobakp1Rzvi+UOaNXk98DBorx0KC BnaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=huH/mNxjK+YnNLpFi8H0WB//O+q9s3l6Xm1guckOifk=; b=aCh6JaVPXclUEVsMT3hfwmPiqORrR8IJ3smnD2Tc7piY8C04T45jA6q5Dope/gpO2r GbiPRa8M6UXEHOasg/plMFN1bz8gYZyNlFwWW3ALaZ/19E4d8LQq4g8OJjmsEKZSY4RN PsB2zexbicytOnjQIK65CPttPdm9sgbB96A7v6OVetE65oj/5lkNnLKes7AEiOoC3j3l mVB9Ga1r32EBdFA1ywwjgF02J1Uj7jR64W5fBLayPv7jql9w1WD+w8MivQ1is3jEfuW7 UQAigt/DTkIa0wpdTdcXQ2pD/bEnj7W7PAvY2FWluFfQip9rlw97dipa9jeQGrmlHRJZ 1N9w== X-Gm-Message-State: ALyK8tI9GN3TOGH9ymcOgGarVG+e6bZHzgGSSezPTKxvLBMI8/WCzNzV76KoFBga/ZPfXh3Wwth+BJ+Efc+xGA== X-Received: by 10.107.133.93 with SMTP id h90mr21233006iod.16.1468594410894; Fri, 15 Jul 2016 07:53:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Fri, 15 Jul 2016 07:53:30 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> From: Warner Losh Date: Fri, 15 Jul 2016 08:53:30 -0600 X-Google-Sender-Auth: qJAJpCDhQDIPISrYOF7R2gn8raU Message-ID: Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: Karl Denninger Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 14:53:32 -0000 I saw your failok PR. That's a good idea. A better idea, though, is to implement true dual-console mode where both the kernel *AND* /etc/rc run on both the serial and the video consoles. I've poked at this in the past, but have never had time to fully implement it due to other things being more pressing. Warner On Fri, Jul 15, 2016 at 8:44 AM, Karl Denninger wrote: > On 7/15/2016 09:22, Paul Mather wrote: > >> On Jul 15, 2016, at 9:44 AM, Karl Denninger wrote: >> >>> On 7/15/2016 08:36, Paul Mather wrote: >>>> On Jul 14, 2016, at 11:36 PM, Karl Denninger wrot= e: >>>> >>>>> Found it. >>>>> >>>>> Apparently the current code *requires* the label be set on the msdos >>>>> partition. If it's not then not only does it not mount (which should= n't >>>>> matter post-boot as the loader is supposed to pass the dtb file, it i= s >>>>> specified in the config file without any sort of path prefix, and thu= s >>>>> once the kernel has loaded it should not matter if the dos partition = if >>>>> actually mounted or not) *but* the boot process hangs without any >>>>> indication of why! >>>>> >>>>> So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} >>>>> >>>>> If the "-L" is missing you're hosed; the system facially appears to b= e >>>>> just fine but while the loader comes up and so does the kernel, it ha= ngs >>>>> without ever proceeding -- and without any sort of error message >>>>> indicating that it is unable to mount something it needs. >>>> You have to do that because the device entry in the stock /etc/fstab i= s /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part indicates it's using ms-do= s labels. In other words, this is just the same sort of failure you were g= etting when you weren't labelling the UFS partition as "rootfs". Labelling= the file system properly "fixes" the issue, as you would expect. >>>> >>>> It's a misnomer to say the code "requires" labels. It's just that's t= he way the distribution images are currently set up. I have an older Pi th= at predates the current distribution images that just uses /dev/mmcsd0... d= evice names in /etc/fstab. Both approaches work fine. You just need to ma= ke sure the devices you specify in /etc/fstab will actually exist when it c= omes time to mount the corresponding file system. >>> Except that if the root filesystem doesn't mount you get an error, and >>> thus you can figure out what's going on. What excuse is there for not >>> printing an error message if a mount fails, and if something in >>> /etc/fstab fails to mount what's with hanging the machine? I've had >>> disks be unavailable before on Intel architecture machines (it happens >>> when disks fail) and the result is an error on the failure to mount but= , >>> unless it's the root volume, the system still comes up. >> >> Are you sure you don't get an error? When I forgot to label rootfs rece= ntly when I cloned an SD card I got an error displayed on the serial consol= e. I didn't get an error on the HDMI screen console. > You get an error if rootfs is not labelled on the HDMI screen (as root > fails to mount.) There is *no* error on an HDMI screen if the msdosfs is > not labeled. >> As I've mentioned before directly, FreeBSD/arm acts like console=3D"comc= onsole,vidconsole" is in effect. This means that during /etc/rc boot proce= ssing, you'll only get output on comconsole (except for kernel messages, wh= ich seem to go to both). That's been my experience in FreeBSD in general. >> >> I dimly recall folks on here saying U-Boot doesn't currently enable/supp= ort USB keyboards, so there's not really much you can do to fix it interact= ively if you fail to boot the OS and hence enable USB keyboard support via = FreeBSD. That's not a problem if you use a serial console, which is suppor= ted by U-Boot. > Well, that's not true if the kernel is loaded. Once the kernel loads a > usb keyboard works. >> >> I'm not sure comparisons with Intel architecture machines is entirely ap= propriate as they use a different boot environment/mechanism. Still, I sta= nd by the fact that I've always got an error message on the serial console = when disks on my FreeBSD/arm system have failed to mount at boot. (It used= to happen regularly with an external USB drive I had that took a long time= to probe, and I ended up having to put a kern.cam.boot_delay in /boot/load= er.conf to avoid the system dropping into single-user mode when doing a reb= oot.) >> >> >>>> If you stop using labels in your /etc/fstab then you won't have proble= ms when those labels are missing. If the labels are missing, the /dev/{msd= osfs,ufs} devices will not be present and the system will drop to single-us= er mode because none-late, non-noauto file systems can't be accessed via th= eir device nodes when attempting to mount them. When that happens and you = don't have a serial console enabled then you have problems remediating the = situation. >>>> >>>> If a file system is not needed to mount as part of booting (as you sug= gest for /boot/msdos) then you should probably flag it with the "noauto" op= tion in /etc/fstab or remove it from /etc/fstab entirely. >>>> >>>> I think the problem you were having is not copying all the required at= tributes of the file systems in question when cloning your SD cards, given = your /etc/fstab setup. It sounds like you've fixed that, now. >>> Again, if it dropped to single user mode *and said it was doing so* or >>> if there was an error message on the console when the filesystem failed >>> to mount I would have found this in a reasonable period of time. It >>> wasn't that rough to do so with the ufs label once I knew the filesyste= m >>> was failing to mount, which was discernible from the console output. >>> >>> Not printing an error when things error out is rude at best, and when >>> that error is going to prevent the system from coming up this darn well >>> ought to show up where one with a monitor plugged in can see it, eh? >>> >>> There was literally no indication at all as to what was going on and >>> since gpart does not show filesystem labels for *either* BSD labeled >>> slices OR msdos figuring out what was different between the two proved >>> to be a bit troublesome. IMHO at least the failure to display an error >>> message in this circumstance ought to be corrected. >> >> See above re: serial console vs. video console. >> >> As for the labels, these are file system labels and not partition labels= . The big clue is in the device name in /etc/fstab. (The "-l" option to "= gpart show" will only show labels "[f]or partitioning schemes that support = partition labels". That's reasonable, IMHO, as partitions are not the same= as file systems and gpart is concerned with partitions.) In my experience= , complaints about not being able to access /dev/ufs/something means you fo= rgot to label a UFS file system as "something" when you made it. :-) >> >> Cheers, >> >> Paul. > > Understood, but the issue here is that there's no indication without a > serial console that you have anything wrong -- the system appears to > have simply hung. > > The quick fix is to put "failok" (or noauto) in the default /etc/fstab > entry for the dos filesystem, since it is not necessary for that > filesystem to be mounted at all on a running machine. If there is a > policy reason to leave it accessible (and there's a fairly-clean > argument that there is) then "failok" might be preferable to "noauto", > but either way forcing a filesystem that is not necessary to be > accessible or the system fails to come up and does not give any > indication of same on what many users will have accessible to them is > facially wrong. > > These devices are thought of as "appliances" by many and as such the > model of USB keyboard + HDMI (e.g. TV or monitor) is entirely > reasonable, and IMHO FreeBSD ought to, when possible, make that a viable > option. It both is and can be provided the kernel loads, but the > defaults in pre-built configurations right now preclude that. > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Fri Jul 15 15:28:36 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F263B99121 for ; Fri, 15 Jul 2016 15:28:36 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 DF27E1C92 for ; Fri, 15 Jul 2016 15:28:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id BF33944CC3C for ; Fri, 15 Jul 2016 10:28:34 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> From: Karl Denninger To: freebsd-arm Message-ID: <7ec73971-bc45-3e3c-2cb2-9ec9b9df3a4f@denninger.net> Date: Fri, 15 Jul 2016 10:28:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030704040203050106050807" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 15:28:36 -0000 This is a cryptographically signed message in MIME format. --------------ms030704040203050106050807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/15/2016 09:53, Warner Losh wrote: > I saw your failok PR. That's a good idea. > > A better idea, though, is to implement true dual-console mode where > both the kernel *AND* /etc/rc run on both the serial and the video > consoles. I've poked at this in the past, but have never had time to > fully implement it due to other things being more pressing. > > Warner Agreed. The best option is the one that exposes what is going on in a way that is *usable* to those in any reasonable set of expected "base" configurations. But for now "failok" is better than nothing. BTW I've run into some very nasty microSD card failure modes of late on these devices and suspect that atime is thrashing them in terms of write endurance, resulting in the destruction of several cards after approximately 9 months of "always on" use. The symptom is that you wind up with a hard error in a given location on the card and there's nothing you can do about it; this results in repeated panics. This has now destroyed three Sandisk 32Gb cards here in the last two weeks, all on different Pi2s doing different things, two of which were on UPS-protected power and thus hadn't taken unprotected shutdowns. As a result I am now mounting root "noatime" which should materially decrease the write load. For most users with these devices in common configurations that isn't going to include a serial console. Hell, I don't usually have one hooked up, although I *can*, because it's just flat-out simpler to plug in a monitor and USB keyboard. For the common person who buys a Pi2 to screw around they will likely not have a serial console available to them at all. Indeed the opposite situation exists in the Intel world; it's a royal PITA to run serial as a primary console that "just works" on servers (in fact I've never found the "recipe" for doing so that doesn't leave me with an exposure where a particular mode of failure might leave me with no way to get in and resolve whatever is broken, including BIOS access), which is why built-in IPMI KVMs are such a big deal on those boards -- they "just work" for the "expected" circumstance that "mirrors" what the common user expects and has. BTW uboot is allegedly able to support a USB keyboard. I don't know if the version we are currently using does, but it allegedly is capable of doing so in the current code that is out there. In addition, how does one change the 10 second boot delay in the current kernel to something shorter? /boot/loader.conf is ignored on ARM systems since they're loaded with uboot, yes? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030704040203050106050807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxNTI4MzJaME8GCSqGSIb3DQEJBDFCBEDH MS+i6qyu44bkmWjLcyfFC6GGtpaJ/gt9GuoxnGHTrNiRCqw5AmgxuXMbdyILfFwFeziYhkxV CGpkHIG0tuW1MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAuPF40gzl kpqdhdWpIS+HWEquYjGex3qKD07rnE4mIbJhDNe9UF04WVnW8arj+NNi055p4a7Pvf3cUudy +OR/j3pSHfI9TU1H/SQKEKQQPfr33r9ktTIQ0jIi007Xd/PINeJUORM+gb+zrfaQ7LbJZYLw zp2k3PGeAHG52eCMNRvBY/iVHY5TispTD4HJAaPkjg7pnvN2d310DeAE11ujIBdjRl/IVOT/ TLRf8XbMR1bNPQTMUZ+JNqoGRe2tAbO1RcVlKhHwXWLcknUc7zSU2TlGzTPgYtlzoPU/wd62 35plZjaoZGr7GI3quIyX66zGgKCbIUdP5NZblRfDCUYm5LOg+xvbz/Milv23GkV1U1Ly0LLS 7HWPBWIc9V9HDl7GCSY3Np6DjTSODv9tYoDVt091WKFwLCvnVJjjPIIWulkUcfC5+ZTwUrWB M0s7pXOetrt4tTdEgK1RAxxvbp/+hyuulEvn3V8Gmr64qKhg/FKVRGTAQXMu6trQ9IOCmmoc BVVTX+ESlDo8hpc9zkgpL/rBg++H5YsFS0OPIHBYw3Ard2eq8ORaxmYPVPV06TG4XUrdMaLl wMQDllVGL4s3v137VQWMG9AurpChcs3WuKlZVJa3O+r8VBFMEDPJhsJOswT4TQW0tyTKKVDB 8/5oL4tkWH9JjbKN3OjSdDY+Os4AAAAAAAA= --------------ms030704040203050106050807-- From owner-freebsd-arm@freebsd.org Fri Jul 15 15:47:21 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C37E0B9998F for ; Fri, 15 Jul 2016 15:47:21 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C721115C for ; Fri, 15 Jul 2016 15:47:21 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 7C7E8A1F; Fri, 15 Jul 2016 11:47:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Paul Mather In-Reply-To: <7ec73971-bc45-3e3c-2cb2-9ec9b9df3a4f@denninger.net> Date: Fri, 15 Jul 2016 11:47:19 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <7ec73971-bc45-3e3c-2cb2-9ec9b9df3a4f@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 15:47:21 -0000 On Jul 15, 2016, at 11:28 AM, Karl Denninger wrote: [[...]] > In addition, how does one change the 10 second boot delay in the = current > kernel to something shorter? /boot/loader.conf is ignored on ARM = systems > since they're loaded with uboot, yes? Put 'autoboot_delay=3D"5"' in /boot/loader.conf to change it to 5 = seconds, for example. The /boot/loader.conf file is not ignored on FreeBSD/arm systems. As I = understand it, U-Boot at some point runs ubldr, which is the normal = FreeBSD loader mechanism that knows how to load the kernel; process = /boot/loader.conf settings; and so on. It works on my systems, anyway. = (I just tested the autoboot_delay setting in fact.) Note that U-Boot also has a (3-second?) boot delay. I don't know how to = change that. Cheers, Paul.= From owner-freebsd-arm@freebsd.org Fri Jul 15 15:47:27 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F412DB999A7 for ; Fri, 15 Jul 2016 15:47:26 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C36DA1192 for ; Fri, 15 Jul 2016 15:47:26 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id C9A6FA21; Fri, 15 Jul 2016 11:47:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Paul Mather In-Reply-To: <7ec73971-bc45-3e3c-2cb2-9ec9b9df3a4f@denninger.net> Date: Fri, 15 Jul 2016 11:47:25 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4667E177-D9E3-4741-95B4-D6C41D44834D@gromit.dlib.vt.edu> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <7ec73971-bc45-3e3c-2cb2-9ec9b9df3a4f@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 15:47:27 -0000 On Jul 15, 2016, at 11:28 AM, Karl Denninger wrote: [[...]] > In addition, how does one change the 10 second boot delay in the = current > kernel to something shorter? /boot/loader.conf is ignored on ARM = systems > since they're loaded with uboot, yes? Put 'autoboot_delay=3D"5"' in /boot/loader.conf to change it to 5 = seconds, for example. The /boot/loader.conf file is not ignored on FreeBSD/arm systems. As I = understand it, U-Boot at some point runs ubldr, which is the normal = FreeBSD loader mechanism that knows how to load the kernel; process = /boot/loader.conf settings; and so on. It works on my systems, anyway. = (I just tested the autoboot_delay setting in fact.) Note that U-Boot also has a (3-second?) boot delay. I don't know how to = change that. Cheers, Paul.= From owner-freebsd-arm@freebsd.org Fri Jul 15 15:49:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C802B99A0C for ; Fri, 15 Jul 2016 15:49:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 EA2911252 for ; Fri, 15 Jul 2016 15:49:30 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 66ECC44CD4D for ; Fri, 15 Jul 2016 10:49:28 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <7ec73971-bc45-3e3c-2cb2-9ec9b9df3a4f@denninger.net> From: Karl Denninger Message-ID: <0292910b-db8a-0147-4e7e-9ed4197aee49@denninger.net> Date: Fri, 15 Jul 2016 10:49:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090800000400090604020005" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 15:49:31 -0000 This is a cryptographically signed message in MIME format. --------------ms090800000400090604020005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/15/2016 10:47, Paul Mather wrote: > On Jul 15, 2016, at 11:28 AM, Karl Denninger wrote= : > > [[...]] > >> In addition, how does one change the 10 second boot delay in the curre= nt >> kernel to something shorter? /boot/loader.conf is ignored on ARM syste= ms >> since they're loaded with uboot, yes? > > Put 'autoboot_delay=3D"5"' in /boot/loader.conf to change it to 5 secon= ds, for example. > > The /boot/loader.conf file is not ignored on FreeBSD/arm systems. As I= understand it, U-Boot at some point runs ubldr, which is the normal Free= BSD loader mechanism that knows how to load the kernel; process /boot/loa= der.conf settings; and so on. It works on my systems, anyway. (I just t= ested the autoboot_delay setting in fact.) Aha. Thank you; I believed that loader.conf WAS ignored. > Note that U-Boot also has a (3-second?) boot delay. I don't know how t= o change that. > > Cheers, > > Paul. That can be changed in config.txt, along with probing USB (e.g. keyboards), provided the uboot is of late enough revision. Now if FreeBSD would do dual-console on boot..... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090800000400090604020005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxNTQ5MjZaME8GCSqGSIb3DQEJBDFCBECi GlCw8fP8rR27j7cVoqZfHcrshYA2vy4Tii1AqR2aPPH6MyT+xw/qXRfOTeC1AEeWF1ETsEMa 1r21y80SxDf+MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAJPbYW6vy 6H4wCzuBQfm53eyxhhNIqQpoag7yhNJb9Pfn0m7m3NQXHyyhzbrDNfT1Q5Egsw3yjiLYyeaC FkHc9ZTmczYUiRZQdUFMGJfrj+UmdswBw4ya/5olZrfcEnwdsmgvtCBfisgRo3Gb+aMr073s ky1S949x/ecb7lNMCK176ZefV6mZiDky3VNASJpHetKeWIvVdHCFEeBS+B1pdL1SZCsgqM1j ufPhB3fJkZD47U8siMTRzoY93cPJy5jtoMeRXX1Ri1vnzbbI9Sdp18tUBQV4IeHlUNEluKSU LqgIVfAOqKsS2OQsXnaS1GhMxMMmbJ4++qOmFlWmGcsWctuX4lkxAXD20V17cIm8KksEA2A9 pAUkHTRgMOwyCrh7szNeZy56IFVSNkYUxxGXEwdSFTscgS7OWNZJmaGEx/4aRi6ZcLZ66/vi ETPhQNIrv4C5+6v9qsujAuKGGLqI7TQtUUHfCIXZDSSDdh5dljKbiNlTYKydS1Bp/iD0m0z3 0LT+5AGjIVIsVJPvCx3VBRT5Jo/LZUcnMpbHskZRQ965tL62swEcTMGXxWMRbQhDTfyeLbax 8XgTI7d9kKueJ6uTbTiKrnR8A1ukZwlpdqYZVpQUL0HsHQqU2zhS0SauyC1GCRqN0G9kWGlb Z4WX/8NSVEaKeL4ftG21sT6FRpkAAAAAAAA= --------------ms090800000400090604020005-- From owner-freebsd-arm@freebsd.org Fri Jul 15 15:51:28 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 343EFB9A105 for ; Fri, 15 Jul 2016 15:51:28 +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 0B54A1629 for ; Fri, 15 Jul 2016 15:51:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1dda138e-4aa4-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 15 Jul 2016 15:52:21 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6FFpPqU009159; Fri, 15 Jul 2016 09:51:25 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468597885.72182.286.camel@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Ian Lepore To: Karl Denninger , freebsd-arm Date: Fri, 15 Jul 2016 09:51:25 -0600 In-Reply-To: References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 15:51:28 -0000 On Fri, 2016-07-15 at 09:44 -0500, Karl Denninger wrote: > On 7/15/2016 09:22, Paul Mather wrote: > > > On Jul 15, 2016, at 9:44 AM, Karl Denninger > > wrote: > > > > > On 7/15/2016 08:36, Paul Mather wrote: > > > > On Jul 14, 2016, at 11:36 PM, Karl Denninger < > > > > karl@denninger.net> wrote: > > > > > > > > > Found it. > > > > > > > > > > Apparently the current code *requires* the label be set on > > > > > the msdos > > > > > partition. If it's not then not only does it not mount > > > > > (which shouldn't > > > > > matter post-boot as the loader is supposed to pass the dtb > > > > > file, it is > > > > > specified in the config file without any sort of path prefix, > > > > > and thus > > > > > once the kernel has loaded it should not matter if the dos > > > > > partition if > > > > > actually mounted or not) *but* the boot process hangs without > > > > > any > > > > > indication of why! > > > > > > > > > > So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} > > > > > > > > > > If the "-L" is missing you're hosed; the system facially > > > > > appears to be > > > > > just fine but while the loader comes up and so does the > > > > > kernel, it hangs > > > > > without ever proceeding -- and without any sort of error > > > > > message > > > > > indicating that it is unable to mount something it needs. > > > > You have to do that because the device entry in the stock > > > > /etc/fstab is /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part > > > > indicates it's using ms-dos labels. In other words, this is > > > > just the same sort of failure you were getting when you weren't > > > > labelling the UFS partition as "rootfs". Labelling the file > > > > system properly "fixes" the issue, as you would expect. > > > > > > > > It's a misnomer to say the code "requires" labels. It's just > > > > that's the way the distribution images are currently set up. I > > > > have an older Pi that predates the current distribution images > > > > that just uses /dev/mmcsd0... device names in /etc/fstab. Both > > > > approaches work fine. You just need to make sure the devices > > > > you specify in /etc/fstab will actually exist when it comes > > > > time to mount the corresponding file system. > > > Except that if the root filesystem doesn't mount you get an > > > error, and > > > thus you can figure out what's going on. What excuse is there > > > for not > > > printing an error message if a mount fails, and if something in > > > /etc/fstab fails to mount what's with hanging the machine? I've > > > had > > > disks be unavailable before on Intel architecture machines (it > > > happens > > > when disks fail) and the result is an error on the failure to > > > mount but, > > > unless it's the root volume, the system still comes up. > > > > Are you sure you don't get an error? When I forgot to label rootfs > > recently when I cloned an SD card I got an error displayed on the > > serial console. I didn't get an error on the HDMI screen console. > You get an error if rootfs is not labelled on the HDMI screen (as > root > fails to mount.) There is *no* error on an HDMI screen if the msdosfs > is > not labeled. > > As I've mentioned before directly, FreeBSD/arm acts like > > console="comconsole,vidconsole" is in effect. This means that > > during /etc/rc boot processing, you'll only get output on > > comconsole (except for kernel messages, which seem to go to both). > > That's been my experience in FreeBSD in general. > > > > I dimly recall folks on here saying U-Boot doesn't currently > > enable/support USB keyboards, so there's not really much you can do > > to fix it interactively if you fail to boot the OS and hence enable > > USB keyboard support via FreeBSD. That's not a problem if you use > > a serial console, which is supported by U-Boot. > Well, that's not true if the kernel is loaded. Once the kernel loads > a > usb keyboard works. > > > > I'm not sure comparisons with Intel architecture machines is > > entirely appropriate as they use a different boot > > environment/mechanism. Still, I stand by the fact that I've always > > got an error message on the serial console when disks on my > > FreeBSD/arm system have failed to mount at boot. (It used to > > happen regularly with an external USB drive I had that took a long > > time to probe, and I ended up having to put a kern.cam.boot_delay > > in /boot/loader.conf to avoid the system dropping into single-user > > mode when doing a reboot.) > > > > > > > > If you stop using labels in your /etc/fstab then you won't have > > > > problems when those labels are missing. If the labels are > > > > missing, the /dev/{msdosfs,ufs} devices will not be present and > > > > the system will drop to single-user mode because none-late, non > > > > -noauto file systems can't be accessed via their device nodes > > > > when attempting to mount them. When that happens and you don't > > > > have a serial console enabled then you have problems > > > > remediating the situation. > > > > > > > > If a file system is not needed to mount as part of booting (as > > > > you suggest for /boot/msdos) then you should probably flag it > > > > with the "noauto" option in /etc/fstab or remove it from > > > > /etc/fstab entirely. > > > > > > > > I think the problem you were having is not copying all the > > > > required attributes of the file systems in question when > > > > cloning your SD cards, given your /etc/fstab setup. It sounds > > > > like you've fixed that, now. > > > Again, if it dropped to single user mode *and said it was doing > > > so* or > > > if there was an error message on the console when the filesystem > > > failed > > > to mount I would have found this in a reasonable period of time. > > > It > > > wasn't that rough to do so with the ufs label once I knew the > > > filesystem > > > was failing to mount, which was discernible from the console > > > output. > > > > > > Not printing an error when things error out is rude at best, and > > > when > > > that error is going to prevent the system from coming up this > > > darn well > > > ought to show up where one with a monitor plugged in can see it, > > > eh? > > > > > > There was literally no indication at all as to what was going on > > > and > > > since gpart does not show filesystem labels for *either* BSD > > > labeled > > > slices OR msdos figuring out what was different between the two > > > proved > > > to be a bit troublesome. IMHO at least the failure to display an > > > error > > > message in this circumstance ought to be corrected. > > > > See above re: serial console vs. video console. > > > > As for the labels, these are file system labels and not partition > > labels. The big clue is in the device name in /etc/fstab. (The " > > -l" option to "gpart show" will only show labels "[f]or > > partitioning schemes that support partition labels". That's > > reasonable, IMHO, as partitions are not the same as file systems > > and gpart is concerned with partitions.) In my experience, > > complaints about not being able to access /dev/ufs/something means > > you forgot to label a UFS file system as "something" when you made > > it. :-) > > > > Cheers, > > > > Paul. > > Understood, but the issue here is that there's no indication without > a > serial console that you have anything wrong -- the system appears to > have simply hung. > > The quick fix is to put "failok" (or noauto) in the default > /etc/fstab > entry for the dos filesystem, since it is not necessary for that > filesystem to be mounted at all on a running machine. If there is a > policy reason to leave it accessible (and there's a fairly-clean > argument that there is) then "failok" might be preferable to > "noauto", > but either way forcing a filesystem that is not necessary to be > accessible or the system fails to come up and does not give any > indication of same on what many users will have accessible to them is > facially wrong. > > These devices are thought of as "appliances" by many and as such the > model of USB keyboard + HDMI (e.g. TV or monitor) is entirely > reasonable, and IMHO FreeBSD ought to, when possible, make that a > viable > option. It both is and can be provided the kernel loads, but the > defaults in pre-built configurations right now preclude that. > I'm having a hard time understanding how a problem report got generated about all this, or how any of it is anything other than "Karl misconfigured his system." The downloadable system images work correctly. You made a local change (formatted new media) and depending on how you want to look at it, either you didn't format correctly or you didn't make your config files match the way you formatted, and that made your system stop working. It doesn't mean there is anything wrong about the way the downloadable images are generated. Changing fstab in the distributed images so that a failure to mount a filesystem becomes a non-error seems like a bad idea to me. The only way that problem happens with a downloaded image is if the image wasn't burned successfully, and that doesn't seem like something that needs to just get papered over just because in your use-case you don't really need the filesystem that failed to mount. A PR about the fact that it hung without visibly reporting an error may be appropriate. A PR that says we should just paper over the error because you don't care about it doesn't seem appropriate. -- Ian From owner-freebsd-arm@freebsd.org Fri Jul 15 16:02:46 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DC76B9A4D9 for ; Fri, 15 Jul 2016 16:02:46 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 C58B91E71 for ; Fri, 15 Jul 2016 16:02:45 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 5BB8444CE03 for ; Fri, 15 Jul 2016 11:02:44 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <1468597885.72182.286.camel@freebsd.org> From: Karl Denninger Message-ID: Date: Fri, 15 Jul 2016 11:02:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1468597885.72182.286.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030902010606030503030506" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 16:02:46 -0000 This is a cryptographically signed message in MIME format. --------------ms030902010606030503030506 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/15/2016 10:51, Ian Lepore wrote: > On Fri, 2016-07-15 at 09:44 -0500, Karl Denninger wrote: >> >> These devices are thought of as "appliances" by many and as such the >> model of USB keyboard + HDMI (e.g. TV or monitor) is entirely >> reasonable, and IMHO FreeBSD ought to, when possible, make that a >> viable >> option. It both is and can be provided the kernel loads, but the >> defaults in pre-built configurations right now preclude that. >> > I'm having a hard time understanding how a problem report got generated= > about all this, or how any of it is anything other than "Karl > misconfigured his system." ERROR means, well, ERROR. A filesystem that is not necessary to be mounted for system operation should not prevent the system from starting normally. Thus, the PR. > The downloadable system images work correctly. You made a local change= > (formatted new media) and depending on how you want to look at it, > either you didn't format correctly or you didn't make your config files= > match the way you formatted, and that made your system stop working.=20 > It doesn't mean there is anything wrong about the way the downloadable= > images are generated. > > Changing fstab in the distributed images so that a failure to mount a > filesystem becomes a non-error seems like a bad idea to me. The only > way that problem happens with a downloaded image is if the image wasn't= > burned successfully, and that doesn't seem like something that needs to= > just get papered over just because in your use-case you don't really > need the filesystem that failed to mount. > > A PR about the fact that it hung without visibly reporting an error may= > be appropriate. A PR that says we should just paper over the error > because you don't care about it doesn't seem appropriate. > > -- Ian It is only appropriate to halt startup if starting in the presence of the condition in question would in some way be harmful to normal operation. Since the contents of the msdos partition are *never* referenced by the running system once the kernel loads, and the kernel has loaded before it tries mounting the partition that winds up denying startup if the mount fails this is a demonstrably incorrect entry in /etc/fstab. You're not papering over anything in this instance; "failok" results in the non-necessary mount's failure not causing startup to fail, which is the obvious and analytically correct choice. Whether the failure to mount is caused by later modification of the filesystem's label or a misconfiguration is immaterial since that particular aspect of the configuration (the label and its use in /etc/fstab) *is not necessary* for the system to boot and run correctly. Declaring something critical to operation that is not in fact necessary for normal operation is nonsense and harmful; the present situation is akin to declaring the absence of the aesni.ko module in /boot/kernel to be a valid reason to prevent startup even though the processor on which you just booted doesn't have AESNI instructions! --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030902010606030503030506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxNjAyNDFaME8GCSqGSIb3DQEJBDFCBECt nW4isDBd0wCMHOG7gwAkkJ0MTi7Dnfa9Q47KIug7UEPP7abbX1V5L0BG9vkBkcG3REh5oQ6W HcjLPHqrgOq7MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAgohCeq+v 9Nj5/aatZK87oZuPP1L8mIyvTWdqAljd6OKxBrLVupOmcmgIRD5ATtTkbTxs3llzNb1Fa7z3 Blaw/IRBzGFiWAxZTf75jQRVXSapb4k+qrB186ZNEnO7P0f2GFOpGhhV8GcntZFHaYfSkHVk rze4gsy+StGXPyECGIAfgkGKL+JeQIdm9nYjakWX6XTVfYk+EJVmcL6+5rJa1asFUFLOBHtl Z5PhRtYucEqjMJOTjHtBkYth4jpayApZKenszNOngfbxNvurpyQ/fu46PKB9loQKyB9Mb1Aw 8P+wWD/h/ST6J8SZyB3S1zbsMU20DS5lZm0qqSLn2/5HX2THSW+gIZyu84hwuAiJ9afuk/36 rxpNHMqSi4M7obU3DMnCTQLVpPVa6z9hXCUyQCUFe2lT3vF+63O/GPTwdZ827zVe4IH8y4yT 5RFsMe/IwP2rs56fu/wzvwJXNQ8X0XHhrUV0lorNS9PAQHkDGlOCmkClBqp/+uv8OBwsy2fN OPGHpiNw1Q6Sl9Ch00KbRaWT3aL5ocCLzr9bIno0834KNf/JQ2sVJT7xAYupfyeGPD2O/iqZ vDgBRUOQV6FcKpca4aXNoXcUovb9VppOJny550RzgxQEEs4v9+7fv0iYCVzZvFJAdcmA9u3z XpZgxd23Gq9btx9Oci8bXUMApAoAAAAAAAA= --------------ms030902010606030503030506-- From owner-freebsd-arm@freebsd.org Fri Jul 15 16:31:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8485B9AF51 for ; Fri, 15 Jul 2016 16:31:38 +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 638AE18DF for ; Fri, 15 Jul 2016 16:31:37 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9b25e0e1-4aa9-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 15 Jul 2016 16:31:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6FGVQLd009268; Fri, 15 Jul 2016 10:31:26 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468600286.72182.311.camel@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Ian Lepore To: Karl Denninger , freebsd-arm Date: Fri, 15 Jul 2016 10:31:26 -0600 In-Reply-To: References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <1468597885.72182.286.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 16:31:39 -0000 On Fri, 2016-07-15 at 11:02 -0500, Karl Denninger wrote: > On 7/15/2016 10:51, Ian Lepore wrote: > > On Fri, 2016-07-15 at 09:44 -0500, Karl Denninger wrote: > > > > > > These devices are thought of as "appliances" by many and as such > > > the > > > model of USB keyboard + HDMI (e.g. TV or monitor) is entirely > > > reasonable, and IMHO FreeBSD ought to, when possible, make that a > > > viable > > > option. It both is and can be provided the kernel loads, but the > > > defaults in pre-built configurations right now preclude that. > > > > > I'm having a hard time understanding how a problem report got > > generated > > about all this, or how any of it is anything other than "Karl > > misconfigured his system." > ERROR means, well, ERROR. > Exactly. Which is why hiding the error by adding "nofail" to the mount for it is, well, the wrong thing to do. > A filesystem that is not necessary to be mounted for system operation > should not prevent the system from starting normally. Thus, the PR. > Why do you think that this is "not necessary" just because you don't happen to use it? There are configuration files on that filesystem (su ch as uEnv.txt) which are there specifically so that userland software has the ability to control the u-boot environment. -- Ian > > The downloadable system images work correctly. You made a local > > change > > (formatted new media) and depending on how you want to look at it, > > either you didn't format correctly or you didn't make your config > > files > > match the way you formatted, and that made your system stop > > working. > > It doesn't mean there is anything wrong about the way the > > downloadable > > images are generated. > > > > Changing fstab in the distributed images so that a failure to mount > > a > > filesystem becomes a non-error seems like a bad idea to me. The > > only > > way that problem happens with a downloaded image is if the image > > wasn't > > burned successfully, and that doesn't seem like something that > > needs to > > just get papered over just because in your use-case you don't > > really > > need the filesystem that failed to mount. > > > > A PR about the fact that it hung without visibly reporting an error > > may > > be appropriate. A PR that says we should just paper over the error > > because you don't care about it doesn't seem appropriate. > > > > -- Ian > It is only appropriate to halt startup if starting in the presence of > the condition in question would in some way be harmful to normal > operation. Since the contents of the msdos partition are *never* > referenced by the running system once the kernel loads, and the > kernel > has loaded before it tries mounting the partition that winds up > denying > startup if the mount fails this is a demonstrably incorrect entry in > /etc/fstab. > > You're not papering over anything in this instance; "failok" results > in > the non-necessary mount's failure not causing startup to fail, which > is > the obvious and analytically correct choice. Whether the failure to > mount is caused by later modification of the filesystem's label or a > misconfiguration is immaterial since that particular aspect of the > configuration (the label and its use in /etc/fstab) *is not > necessary* > for the system to boot and run correctly. > > Declaring something critical to operation that is not in fact > necessary > for normal operation is nonsense and harmful; the present situation > is > akin to declaring the absence of the aesni.ko module in /boot/kernel > to > be a valid reason to prevent startup even though the processor on > which > you just booted doesn't have AESNI instructions! > From owner-freebsd-arm@freebsd.org Fri Jul 15 16:33:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD6D2B9AFE2 for ; Fri, 15 Jul 2016 16:33:16 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ACCDF1A94; Fri, 15 Jul 2016 16:33:16 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 01D44A8D; Fri, 15 Jul 2016 12:33:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Paul Mather In-Reply-To: <1468597885.72182.286.camel@freebsd.org> Date: Fri, 15 Jul 2016 12:33:14 -0400 Cc: Karl Denninger , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <1468597885.72182.286.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 16:33:17 -0000 On Jul 15, 2016, at 11:51 AM, Ian Lepore wrote: > On Fri, 2016-07-15 at 09:44 -0500, Karl Denninger wrote: >> On 7/15/2016 09:22, Paul Mather wrote: >>=20 >>> On Jul 15, 2016, at 9:44 AM, Karl Denninger >>> wrote: >>>=20 >>>> On 7/15/2016 08:36, Paul Mather wrote: >>>>> On Jul 14, 2016, at 11:36 PM, Karl Denninger < >>>>> karl@denninger.net> wrote: >>>>>=20 >>>>>> Found it. >>>>>>=20 >>>>>> Apparently the current code *requires* the label be set on >>>>>> the msdos >>>>>> partition. If it's not then not only does it not mount >>>>>> (which shouldn't >>>>>> matter post-boot as the loader is supposed to pass the dtb >>>>>> file, it is >>>>>> specified in the config file without any sort of path prefix, >>>>>> and thus >>>>>> once the kernel has loaded it should not matter if the dos >>>>>> partition if >>>>>> actually mounted or not) *but* the boot process hangs without >>>>>> any >>>>>> indication of why! >>>>>>=20 >>>>>> So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} >>>>>>=20 >>>>>> If the "-L" is missing you're hosed; the system facially >>>>>> appears to be >>>>>> just fine but while the loader comes up and so does the >>>>>> kernel, it hangs >>>>>> without ever proceeding -- and without any sort of error >>>>>> message >>>>>> indicating that it is unable to mount something it needs. >>>>> You have to do that because the device entry in the stock >>>>> /etc/fstab is /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part >>>>> indicates it's using ms-dos labels. In other words, this is >>>>> just the same sort of failure you were getting when you weren't >>>>> labelling the UFS partition as "rootfs". Labelling the file >>>>> system properly "fixes" the issue, as you would expect. >>>>>=20 >>>>> It's a misnomer to say the code "requires" labels. It's just >>>>> that's the way the distribution images are currently set up. I >>>>> have an older Pi that predates the current distribution images >>>>> that just uses /dev/mmcsd0... device names in /etc/fstab. Both >>>>> approaches work fine. You just need to make sure the devices >>>>> you specify in /etc/fstab will actually exist when it comes >>>>> time to mount the corresponding file system. >>>> Except that if the root filesystem doesn't mount you get an >>>> error, and >>>> thus you can figure out what's going on. What excuse is there >>>> for not >>>> printing an error message if a mount fails, and if something in >>>> /etc/fstab fails to mount what's with hanging the machine? I've >>>> had >>>> disks be unavailable before on Intel architecture machines (it >>>> happens >>>> when disks fail) and the result is an error on the failure to >>>> mount but, >>>> unless it's the root volume, the system still comes up. >>>=20 >>> Are you sure you don't get an error? When I forgot to label rootfs >>> recently when I cloned an SD card I got an error displayed on the >>> serial console. I didn't get an error on the HDMI screen console. >> You get an error if rootfs is not labelled on the HDMI screen (as >> root >> fails to mount.) There is *no* error on an HDMI screen if the msdosfs >> is >> not labeled. >>> As I've mentioned before directly, FreeBSD/arm acts like >>> console=3D"comconsole,vidconsole" is in effect. This means that >>> during /etc/rc boot processing, you'll only get output on >>> comconsole (except for kernel messages, which seem to go to both).=20= >>> That's been my experience in FreeBSD in general. >>>=20 >>> I dimly recall folks on here saying U-Boot doesn't currently >>> enable/support USB keyboards, so there's not really much you can do >>> to fix it interactively if you fail to boot the OS and hence enable >>> USB keyboard support via FreeBSD. That's not a problem if you use >>> a serial console, which is supported by U-Boot. >> Well, that's not true if the kernel is loaded. Once the kernel loads >> a >> usb keyboard works. >>>=20 >>> I'm not sure comparisons with Intel architecture machines is >>> entirely appropriate as they use a different boot >>> environment/mechanism. Still, I stand by the fact that I've always >>> got an error message on the serial console when disks on my >>> FreeBSD/arm system have failed to mount at boot. (It used to >>> happen regularly with an external USB drive I had that took a long >>> time to probe, and I ended up having to put a kern.cam.boot_delay >>> in /boot/loader.conf to avoid the system dropping into single-user >>> mode when doing a reboot.) >>>=20 >>>=20 >>>>> If you stop using labels in your /etc/fstab then you won't have >>>>> problems when those labels are missing. If the labels are >>>>> missing, the /dev/{msdosfs,ufs} devices will not be present and >>>>> the system will drop to single-user mode because none-late, non >>>>> -noauto file systems can't be accessed via their device nodes >>>>> when attempting to mount them. When that happens and you don't >>>>> have a serial console enabled then you have problems >>>>> remediating the situation. >>>>>=20 >>>>> If a file system is not needed to mount as part of booting (as >>>>> you suggest for /boot/msdos) then you should probably flag it >>>>> with the "noauto" option in /etc/fstab or remove it from >>>>> /etc/fstab entirely. >>>>>=20 >>>>> I think the problem you were having is not copying all the >>>>> required attributes of the file systems in question when >>>>> cloning your SD cards, given your /etc/fstab setup. It sounds >>>>> like you've fixed that, now. >>>> Again, if it dropped to single user mode *and said it was doing >>>> so* or >>>> if there was an error message on the console when the filesystem >>>> failed >>>> to mount I would have found this in a reasonable period of time.=20 >>>> It >>>> wasn't that rough to do so with the ufs label once I knew the >>>> filesystem >>>> was failing to mount, which was discernible from the console >>>> output. >>>>=20 >>>> Not printing an error when things error out is rude at best, and >>>> when >>>> that error is going to prevent the system from coming up this >>>> darn well >>>> ought to show up where one with a monitor plugged in can see it, >>>> eh? >>>>=20 >>>> There was literally no indication at all as to what was going on >>>> and >>>> since gpart does not show filesystem labels for *either* BSD >>>> labeled >>>> slices OR msdos figuring out what was different between the two >>>> proved >>>> to be a bit troublesome. IMHO at least the failure to display an >>>> error >>>> message in this circumstance ought to be corrected. >>>=20 >>> See above re: serial console vs. video console. >>>=20 >>> As for the labels, these are file system labels and not partition >>> labels. The big clue is in the device name in /etc/fstab. (The " >>> -l" option to "gpart show" will only show labels "[f]or >>> partitioning schemes that support partition labels". That's >>> reasonable, IMHO, as partitions are not the same as file systems >>> and gpart is concerned with partitions.) In my experience, >>> complaints about not being able to access /dev/ufs/something means >>> you forgot to label a UFS file system as "something" when you made >>> it. :-) >>>=20 >>> Cheers, >>>=20 >>> Paul. >>=20 >> Understood, but the issue here is that there's no indication without >> a >> serial console that you have anything wrong -- the system appears to >> have simply hung. >>=20 >> The quick fix is to put "failok" (or noauto) in the default >> /etc/fstab >> entry for the dos filesystem, since it is not necessary for that >> filesystem to be mounted at all on a running machine. If there is a >> policy reason to leave it accessible (and there's a fairly-clean >> argument that there is) then "failok" might be preferable to >> "noauto", >> but either way forcing a filesystem that is not necessary to be >> accessible or the system fails to come up and does not give any >> indication of same on what many users will have accessible to them is >> facially wrong. >>=20 >> These devices are thought of as "appliances" by many and as such the >> model of USB keyboard + HDMI (e.g. TV or monitor) is entirely >> reasonable, and IMHO FreeBSD ought to, when possible, make that a >> viable >> option. It both is and can be provided the kernel loads, but the >> defaults in pre-built configurations right now preclude that. >>=20 >=20 > I'm having a hard time understanding how a problem report got = generated > about all this, or how any of it is anything other than "Karl > misconfigured his system." >=20 > The downloadable system images work correctly. You made a local = change > (formatted new media) and depending on how you want to look at it, > either you didn't format correctly or you didn't make your config = files > match the way you formatted, and that made your system stop working.=20= > It doesn't mean there is anything wrong about the way the downloadable > images are generated. >=20 > Changing fstab in the distributed images so that a failure to mount a > filesystem becomes a non-error seems like a bad idea to me. The only > way that problem happens with a downloaded image is if the image = wasn't > burned successfully, and that doesn't seem like something that needs = to > just get papered over just because in your use-case you don't really > need the filesystem that failed to mount. >=20 > A PR about the fact that it hung without visibly reporting an error = may > be appropriate. A PR that says we should just paper over the error > because you don't care about it doesn't seem appropriate. Maybe it should be filed as a "feature request" rather than a "bug." = Does Bugzilla support the distinction? I agree with Ian that this is not a bug in the sense that anyone = installing from the distributed images will never trigger it on their = install media. It is reasonable to file a feature request to omit /boot/msdos as a = mandatory mount. I think when I first was using FreeBSD/arm on my = Raspberry Pi it wasn't mounted, but then that predates the current = distribution images. Now it is. I can see arguments either way and the = current setting makes sense to me. I think Warner and Ian hit the nail = on the head that the real issue is the lack of output on the video = console during /etc/rc processing. Incidentally, does setting console=3D"vidconsole" in /boot/loader.conf = fix the problem of a lack of /etc/rc messages for those who are using an = HDMI monitor as their primary/only console? If so, there may also be a = case for making that the default if the assumption is that a minority of = people will be using a serial console. (Not a fair assumption right = now, IMHO, but perhaps a fair one going forward as FreeBSD/arm becomes = Tier 1.) Cheers, Paul. From owner-freebsd-arm@freebsd.org Fri Jul 15 17:29:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2367BB9A36A for ; Fri, 15 Jul 2016 17:29:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.chatusa.com (br1.CN84in.chatusa.com [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 E35521877; Fri, 15 Jul 2016 17:29:53 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.ChatUSA.com (localhost [127.0.0.1]) by pdx.rh.CN85.chatusa.com (8.13.3/8.13.3) with ESMTP id u6FHTTS7068990; Fri, 15 Jul 2016 10:29:29 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3/Submit) id u6FHT9PT068989; Fri, 15 Jul 2016 10:29:09 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... In-Reply-To: To: Paul Mather Date: Fri, 15 Jul 2016 10:29:09 -0700 (PDT) CC: Ian Lepore , freebsd-arm 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.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 17:29:56 -0000 [trimmed]] > > I'm having a hard time understanding how a problem report got generated > > about all this, or how any of it is anything other than "Karl > > misconfigured his system." > > > > The downloadable system images work correctly. You made a local change > > (formatted new media) and depending on how you want to look at it, > > either you didn't format correctly or you didn't make your config files > > match the way you formatted, and that made your system stop working. > > It doesn't mean there is anything wrong about the way the downloadable > > images are generated. > > > > Changing fstab in the distributed images so that a failure to mount a > > filesystem becomes a non-error seems like a bad idea to me. The only > > way that problem happens with a downloaded image is if the image wasn't > > burned successfully, and that doesn't seem like something that needs to > > just get papered over just because in your use-case you don't really > > need the filesystem that failed to mount. > > > > A PR about the fact that it hung without visibly reporting an error may > > be appropriate. A PR that says we should just paper over the error > > because you don't care about it doesn't seem appropriate. > > > Maybe it should be filed as a "feature request" rather than a "bug." Does Bugzilla support the distinction? > > I agree with Ian that this is not a bug in the sense that anyone installing from the distributed images will never trigger it on their install media. So its not a bug because it doesnt happen at install time? Thanks, we can now go close 80% of the PR's as non bugs cause they dont happen in the install image. > It is reasonable to file a feature request to omit /boot/msdos as a mandatory mount. I think when I first was using FreeBSD/arm on my Raspberry Pi it wasn't mounted, but then that predates the current distribution images. Now it is. I can see arguments either way and the current setting makes sense to me. I think Warner and Ian hit the nail on the head that the real issue is the lack of output on the video console during /etc/rc processing. > And that is, IMHO, a bug, and a PR should be opened for it as well. > Incidentally, does setting console="vidconsole" in /boot/loader.conf fix the problem of a lack of /etc/rc messages for those who are using an HDMI monitor as their primary/only console? If so, there may also be a case for making that the default if the assumption is that a minority of people will be using a serial console. (Not a fair assumption right now, IMHO, but perhaps a fair one going forward as FreeBSD/arm becomes Tier 1.) I think the issue of robustness inspite of problems is being ignored on these issues for some reason. Adding nofail to /etc/fstab makes the system far more robust in lite of things that may go wrong. This is a GOOD thing. Having console="vidconsole,comconsole" again is a robustness feature and makes handing install time, or any time later easier to deal with. Documenting that the output of /etc/rc.d/* does not appear on the vid console and that you should look on a serial console if you are experiencing boot time problems would be another robustness feature. Putting noatime, or atleast giving the user an option to, at FreeBSD install time on all SD card mounted file systems would be yet another robustness feature. I know that this is hard to do as the SD images are pre rolled with a hardcoded /etc/fstab at build time. FreeBSD should always strive to be robust inspite of problems, any problem, if the cost to do so is minimal. Adding nofail to the msdos partition fstab entry on the built images is a minimal effort. The tools that try to access this partition from userland well gravefully report errors that the user can easily address. My bike shed is Royal Blue. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Fri Jul 15 17:43:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EB5EB9AA64 for ; Fri, 15 Jul 2016 17:43: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 A0F7017F2; Fri, 15 Jul 2016 17:43: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 u6FHRt2R064805 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Jul 2016 10:27:56 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id u6FHRsaQ064804; Fri, 15 Jul 2016 10:27:54 -0700 (PDT) (envelope-from fbsd) Date: Fri, 15 Jul 2016 10:27:54 -0700 From: bob prohaska To: Paul Mather Cc: Ian Lepore , freebsd-arm , fbsd@www.zefox.net Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <20160715172754.GG33486@www.zefox.net> References: <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <1468597885.72182.286.camel@freebsd.org> 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.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 17:43:59 -0000 On Fri, Jul 15, 2016 at 12:33:14PM -0400, Paul Mather wrote: > > Incidentally, does setting console="vidconsole" in /boot/loader.conf fix the problem of a lack of /etc/rc messages for those who are using an HDMI monitor as their primary/only console? Not with that particular syntax. It just produces a message about "bad definition". HDMI output ends with the kernel probe, resuming with a login prompt. The serial console reports in part: ------begin serial console output------- Uptime: 4d1h42m2s Rebooting... U-Boot 2015.04 (May 30 2015 - 22:13:58) DRAM: 944 MiB WARNING: Caches not enabled RPI 2 Model B MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr reading ubldr 265922 bytes read in 207 ms (1.2 MiB/s) ## Starting application at 0x02000094 ... Consoles: U-Boot console Compatible U-Boot API signature found @3ab4a4c8 FreeBSD/armv6 U-Boot loader, Revision 1.2 (bob@fbsd.zefox.com, Thu Jun 11 08:12:11 PDT 2015) DRAM: 944MB Number of U-Boot devices: 1 U-Boot env: loaderdev='mmc 0' Found U-Boot device: disk Checking unit=0 slice= partition=... good. no such console! Available consoles: uboot Warning: bad definition on file /boot/loader.conf console="vidconsole" /boot/kernel/kernel text=0x5cff4c data=0x55d64+0x15931c syms=[0x4+0x859c0+0x4+0x99be0] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x2200180... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 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 #1 r302526: Mon Jul 11 05:59:37 PDT 2016 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm [omitted kernel probes] Mounting local file systems:. lock order reversal: 1st 0xc48f1db4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2523 2nd 0xd7624db0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xc490eb74 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2523 stack backtrace: ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/gcc48 /usr/local/lib/graphviz /usr/local/lib/nss /usr/local/lib/opencollada /usr/local/lib/perl5/5.20/mach/CORE /usr/local/llvm37/lib random: unblocking device. [more omitted messages] Starting background file system checks in 60 seconds. Fri Jul 15 10:10:05 PDT 2016 FreeBSD/arm (www.zefox.com) (ttyu0) login: ------end serial console output-------- I included the lock order reversal messages as a curiosity; don't recall seeing them before. It's worth noting in passing that the /usr/src/sys/arm/conf/RPI2 config file used in this setup contains the lines: # Comment following lines for boot console on serial port device vt device kbdmux device ukbd The machine _has_ a serial console, and only a serial console, despite the lines not being commented. Are the comment instructions backwards? Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Fri Jul 15 18:03:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBD29B99199 for ; Fri, 15 Jul 2016 18:03:22 +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 6B6F51C04 for ; Fri, 15 Jul 2016 18:03:21 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6ebbfee7-4ab6-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 15 Jul 2016 18:03:27 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6FI3EXW009477; Fri, 15 Jul 2016 12:03:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468605794.72182.320.camel@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Ian Lepore To: "Rodney W. Grimes" , Paul Mather Cc: freebsd-arm Date: Fri, 15 Jul 2016 12:03:14 -0600 In-Reply-To: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 18:03:23 -0000 On Fri, 2016-07-15 at 10:29 -0700, Rodney W. Grimes wrote: > [trimmed]] > > > I'm having a hard time understanding how a problem report got > > > generated > > > about all this, or how any of it is anything other than "Karl > > > misconfigured his system." > > > > > > The downloadable system images work correctly. You made a local > > > change > > > (formatted new media) and depending on how you want to look at > > > it, > > > either you didn't format correctly or you didn't make your config > > > files > > > match the way you formatted, and that made your system stop > > > working. > > > It doesn't mean there is anything wrong about the way the > > > downloadable > > > images are generated. > > > > > > Changing fstab in the distributed images so that a failure to > > > mount a > > > filesystem becomes a non-error seems like a bad idea to me. The > > > only > > > way that problem happens with a downloaded image is if the image > > > wasn't > > > burned successfully, and that doesn't seem like something that > > > needs to > > > just get papered over just because in your use-case you don't > > > really > > > need the filesystem that failed to mount. > > > > > > A PR about the fact that it hung without visibly reporting an > > > error may > > > be appropriate. A PR that says we should just paper over the > > > error > > > because you don't care about it doesn't seem appropriate. > > > > > > Maybe it should be filed as a "feature request" rather than a > > "bug." Does Bugzilla support the distinction? > > > > I agree with Ian that this is not a bug in the sense that anyone > > installing from the distributed images will never trigger it on > > their install media. > > So its not a bug because it doesnt happen at install time? Thanks, > we can > now go close 80% of the PR's as non bugs cause they dont happen in > the > install image. > Excuse me? It's not a bug because: It's not a bug. Go download one of the rpi snapshot or release images. Burn it. Boot it. It works. Now go randomly change something. For example, reformat and repopulate the card in a way that conflicts with what's in /etc/fstab, but don't change fstab to match. Now it doesn't work. In your mind, that's a bug? A bug that should be fixed by changing fstab in our distributed images to ignore failures to mount the filesystems contained in the image? I feel like I've woken up in bizzaro world today. -- Ian > > It is reasonable to file a feature request to omit /boot/msdos as a > > mandatory mount. I think when I first was using FreeBSD/arm on my > > Raspberry Pi it wasn't mounted, but then that predates the current > > distribution images. Now it is. I can see arguments either way > > and the current setting makes sense to me. I think Warner and Ian > > hit the nail on the head that the real issue is the lack of output > > on the video console during /etc/rc processing. > > > > And that is, IMHO, a bug, and a PR should be opened for it as well. > > > Incidentally, does setting console="vidconsole" in > > /boot/loader.conf fix the problem of a lack of /etc/rc messages for > > those who are using an HDMI monitor as their primary/only console? > > If so, there may also be a case for making that the default if the > > assumption is that a minority of people will be using a serial > > console. (Not a fair assumption right now, IMHO, but perhaps a > > fair one going forward as FreeBSD/arm becomes Tier 1.) > > I think the issue of robustness inspite of problems is being ignored > on these issues for > some reason. Adding nofail to /etc/fstab makes the system far more > robust in lite of > things that may go wrong. This is a GOOD thing. > > Having console="vidconsole,comconsole" again is a robustness feature > and makes handing > install time, or any time later easier to deal with. > > Documenting that the output of /etc/rc.d/* does not appear on the vid > console and > that you should look on a serial console if you are experiencing boot > time problems > would be another robustness feature. > > Putting noatime, or atleast giving the user an option to, at FreeBSD > install time > on all SD card mounted file systems would be yet another robustness > feature. I > know that this is hard to do as the SD images are pre rolled with a > hardcoded > /etc/fstab at build time. > > FreeBSD should always strive to be robust inspite of problems, any > problem, if > the cost to do so is minimal. Adding nofail to the msdos partition > fstab > entry on the built images is a minimal effort. > > The tools that try to access this partition from userland well > gravefully > report errors that the user can easily address. > > My bike shed is Royal Blue. From owner-freebsd-arm@freebsd.org Fri Jul 15 18:23:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DF35B99912 for ; Fri, 15 Jul 2016 18:23:32 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 378D118B0 for ; Fri, 15 Jul 2016 18:23:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 41DAF44F044 for ; Fri, 15 Jul 2016 13:23:29 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Uboot RPI2 can get USB to scan, but doesn't see keyboard Message-ID: Date: Fri, 15 Jul 2016 13:23:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080207010807090201000004" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 18:23:32 -0000 This is a cryptographically signed message in MIME format. --------------ms080207010807090201000004 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have successfully patched the u-boot code to obtain a USB scan during pre-boot (so in theory a USB keyboard would work during u-boot time on the Pi) but it appears that something is missing in that either the usb keyboard never attaches (despite being declared as a legitimate input source in stdin) or it is not being picked up in the first place. I'm not sure which is the case and the uboot output doesn't make clear which is the case -- has anyone else worked on this? From what I can discern it *does* work with Linux distributions, so it has to be something in our config file for u-boot and not an inherently impossibility with u-boot on this platform. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080207010807090201000004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxODIzMjZaME8GCSqGSIb3DQEJBDFCBEA+ HYApljLhJ0AWBBIsOJBKoRrDmfugEcpRRlFDjOdLwA3RT4e/I5Yn8tjULFJ2ORszArVfc6Lh 4rfRe5FynvWkMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIABGkVsiqH 0G3Q+45BW6lhkunbjT9xdN8kARFQhFcOhjoWD7phdW0dLGClVkAdQe04ScNkgyFKr7G0CNJO Xmg8R7TGhBnJ7ukFrpg/ad1f/8ca8V1UwFcJ/ISU8l3Xk2hPDkvFjVMdmFSUDk6w0S4xi8ru sgvboFIhf7r18HesGE6izw3g52ndTPwlcYPkfA0L5msCfJU2WqAJ+1qiZjn/pdI1zAA/0CJ3 cr3n1dZH0YdemfSncGq0oydaDrS3hrbshy7t87QGa9qLZaO2bZ8nF5bmAoVjHG5zz9M7VMpE ZOtmsqPHzlzXaqxFTJYlpofcCdQFvKF3iBbzpA6PfvTkNNAIXCKnPJvYWwA1FZny4jjDKs3w hIDsaeR2+tL7uPvKVzL7NkaXuw8sLidivd4fKjwguKQ4h85Fi0vo8csKsYUMQtoB+qqYmb5u KpPfgJpJiF1BqjPssS1VhtH+aY+vzkLt9dhpWxjTkgfPPaXLVRNjIFimtdkqzQULQr28/Ct/ MlmnCBSu5yP9uV1c81Kh7kuZrJ6sD0LWPSC0n3C26OrPGxvq5C2aDePmbo/ZllwTsUf3Xsrh fXFqv+O/gu8uWtW/VIz6MpS7/sbRjydYJHUSB2QYWrdd0a/gZ8MlEkJtMvdk2sjSkR+rAFlX a6CW5xzlpkbixVBSv/0dXMtmHKAAAAAAAAA= --------------ms080207010807090201000004-- From owner-freebsd-arm@freebsd.org Fri Jul 15 18:25:57 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7199AB9999C for ; Fri, 15 Jul 2016 18:25:57 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2881C1979; Fri, 15 Jul 2016 18:25:57 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-yw0-x236.google.com with SMTP id i12so108348862ywa.1; Fri, 15 Jul 2016 11:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2gDviQ6ZQrXhgJZX3CO06CWhSbRlGpCnmDxFJAV12ns=; b=dSVKpaB3IE0/cVmszqLlIeyP8ehfyF6KRbPDPB7vuhzXs8SvxaCK4qGCTmdaEEdvBf F4m9FXydLOX3cUYRvWc5JgH+LMl837rLWF70BMgPKvpqJqpkMjXTcPg7UO7uDTQtqkRd oRTVxuf07IQnInN6SIv5cjt1UVMk6wxG7r/viK/qx720nnSJV8DQ+5ZB1rPFOAC8kpZ4 wXMQkGw2nBCoPcrnU8ShCgP7l3wHtwwFuKFh5IEe+2wIY5tcTg1SbaT2wOlxP31lglDg 3TM7pRv1KcX2ZN89ZPeVYgcMU0mjeZggIuPJEDyvvw4BiCePvps/bw6n5L1uX7TVgK8s Xb3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2gDviQ6ZQrXhgJZX3CO06CWhSbRlGpCnmDxFJAV12ns=; b=OHvX/US5e8eCgwr3z0my3SVwFZWKrmyU75ZKNIp28QaG6sP4CLWrPD56239uFpYEXe /zRNoLbet2vEjppj06ARhVU8KI5wJh9UHJq9ZlsS1MjV1fuTR/eaZGumQ5F/JBJ4WCaC Az/NCF52fbmdrtq+4IFUY4Bc2wp39pkb1DnLIGv6ns6zvRZ8llPE+PcFgjozWin1V5Da bcPAkT7nIYJ/N8L7NmAbFuuinWqsC18SQw1NPB+6+5UYqSRX1Hi9xFWTFn3108npe813 e71/3oHzNbtrdWdHGOr1pmRbBUzH4tzXPhnjek007cbNtFmc5Uss0qb33bpOt/CQyWgT yL9A== X-Gm-Message-State: ALyK8tLDjkI5PyTsPBuh1/HIyaDbcgGR3oHoZ5w1PyqXO4+l8Q5Ji/nGZF3IvkxJVynaQNhkKfqUWLMcd4ueoQ== X-Received: by 10.37.230.202 with SMTP id d193mr14820971ybh.111.1468607156283; Fri, 15 Jul 2016 11:25:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.137.3 with HTTP; Fri, 15 Jul 2016 11:25:55 -0700 (PDT) In-Reply-To: <20160715172754.GG33486@www.zefox.net> References: <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <1468597885.72182.286.camel@freebsd.org> <20160715172754.GG33486@www.zefox.net> From: Luiz Otavio O Souza Date: Fri, 15 Jul 2016 15:25:55 -0300 Message-ID: Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: bob prohaska Cc: Paul Mather , freebsd-arm , Ian Lepore Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 18:25:57 -0000 On 15 July 2016 at 14:27, bob prohaska wrote: > On Fri, Jul 15, 2016 at 12:33:14PM -0400, Paul Mather wrote: >> >> Incidentally, does setting console="vidconsole" in /boot/loader.conf fix the problem of a lack of /etc/rc messages for those who are using an HDMI monitor as their primary/only console? > > Not with that particular syntax. It just produces a message about "bad definition". HDMI > output ends with the kernel probe, resuming with a login prompt. No, setting console to vidconsole doesn't work. See conscontrol(8), the first high level console is always used and in this case, it is the serial console as the vt console comes too late in boot (there is another kind of driver that implements the vt_early support to cope with that, but I can't say if that is a doable solution for RPi - IIRC I once thought it was possible...). That said, I have this _hack_ that changes the high level console to vt once it is attached (not a real solution, just quick test for debug purposes): Index: sys/dev/vt/vt_core.c =================================================================== --- sys/dev/vt/vt_core.c (revision 279665) +++ sys/dev/vt/vt_core.c (working copy) @@ -2686,6 +2686,7 @@ * it. */ termcn_cnregister(vd->vd_windows[VT_CONSWINDOW]->vw_terminal); + cnselect(vd->vd_windows[VT_CONSWINDOW]->vw_terminal->consdev); } static void After the boot you can always change your console device back and forth with the sysctl kern.console. The real solution is implement what Warner said, a real multiple device support for high level console. Luiz From owner-freebsd-arm@freebsd.org Fri Jul 15 18:29:08 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0EF0B99A8E for ; Fri, 15 Jul 2016 18:29:08 +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 28B5F1AFF for ; Fri, 15 Jul 2016 18:29:07 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 084d4bb1-4aba-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 15 Jul 2016 18:29:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6FIT191009510; Fri, 15 Jul 2016 12:29:01 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468607341.72182.330.camel@freebsd.org> Subject: Re: Uboot RPI2 can get USB to scan, but doesn't see keyboard From: Ian Lepore To: Karl Denninger , "freebsd-arm@freebsd.org" Date: Fri, 15 Jul 2016 12:29:01 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 18:29:08 -0000 On Fri, 2016-07-15 at 13:23 -0500, Karl Denninger wrote: > I have successfully patched the u-boot code to obtain a USB scan > during > pre-boot (so in theory a USB keyboard would work during u-boot time > on > the Pi) but it appears that something is missing in that either the > usb > keyboard never attaches (despite being declared as a legitimate input > source in stdin) or it is not being picked up in the first place. > > I'm not sure which is the case and the uboot output doesn't make > clear > which is the case -- has anyone else worked on this? From what I can > discern it *does* work with Linux distributions, so it has to be > something in our config file for u-boot and not an inherently > impossibility with u-boot on this platform. > u-boot on rpi has long been able to handle full speed and high speed devices (not sure what you would have patch, since this has always worked), but not low speed devices such as a keyboard. It may be that mainline u-boot has finally gotten that bug fixed (a fix was said to be in testing when I checked a few months ago). If so, we need to update our u-boot ports for rpi. -- Ian From owner-freebsd-arm@freebsd.org Fri Jul 15 18:37:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2A42B99EF0 for ; Fri, 15 Jul 2016 18:37:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 20437145D for ; Fri, 15 Jul 2016 18:37:33 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id F11D344F105 for ; Fri, 15 Jul 2016 13:37:30 -0500 (CDT) Subject: Re: Uboot RPI2 can get USB to scan, but doesn't see keyboard To: "freebsd-arm@freebsd.org" References: <1468607341.72182.330.camel@freebsd.org> From: Karl Denninger Message-ID: <42808748-214c-3361-399a-cc216c20f77b@denninger.net> Date: Fri, 15 Jul 2016 13:37:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1468607341.72182.330.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010203070800090102060400" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 18:37:35 -0000 This is a cryptographically signed message in MIME format. --------------ms010203070800090102060400 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/15/2016 13:29, Ian Lepore wrote: > On Fri, 2016-07-15 at 13:23 -0500, Karl Denninger wrote: >> I have successfully patched the u-boot code to obtain a USB scan >> during >> pre-boot (so in theory a USB keyboard would work during u-boot time >> on >> the Pi) but it appears that something is missing in that either the >> usb >> keyboard never attaches (despite being declared as a legitimate input >> source in stdin) or it is not being picked up in the first place. >> >> I'm not sure which is the case and the uboot output doesn't make >> clear >> which is the case -- has anyone else worked on this? From what I can >> discern it *does* work with Linux distributions, so it has to be >> something in our config file for u-boot and not an inherently >> impossibility with u-boot on this platform. >> > u-boot on rpi has long been able to handle full speed and high speed > devices (not sure what you would have patch, since this has always > worked), but not low speed devices such as a keyboard. It may be that > mainline u-boot has finally gotten that bug fixed (a fix was said to be= > in testing when I checked a few months ago). If so, we need to update > our u-boot ports for rpi. > > -- Ian Our config file for the 2015-04 port did not specify "usb start" in the preboot stanza so the USB subsystem was never probed by default. You could turn it on via the serial console (if you had one) but not having it there in the first place leads to a chicken-and-egg problem. It also appeared that reading the uEnv.txt file is not enabled so there was no way to 'stuff' that command in (even once) for a system without a serial console. The lack of low-speed may be why although the usb probes the keyboard doesn't attach. The git repo specifically references the following though for the Pi in the defaults file 158 /* Environment */ 159 #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG 160 #define ENV_DEVICE_SETTINGS \ 161 "stdin=3Dserial,usbkbd\0" \ 162 "stdout=3Dserial,lcd\0" \ 163 "stderr=3Dserial,lcd\0" And in addition it ALSO specifies "usb start" in the default preboot stan= za. That STRONGLY implies that the code has been fixed and a USB keyboard will work. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010203070800090102060400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxODM3MjhaME8GCSqGSIb3DQEJBDFCBEC1 DX61PK2tYDE1n9uQvkSowNvRpb1iwyOxECGyLasqosRCvKG80NJ2kO4dbjgEFksZvGsBqbUK SB5vJlxW7BUJMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAcOpN4jmO EA/KO3A+LeLnFIU+PhTurcPE1x8Dy1rg7pOigZXQZjazRyMTQOVmP8NfzlFvPaItaBBhtQOR UpepSySBgZja+AOsI6nhfPVS391lodPa6N3v+I5hEG6Apbpg+7vo9KV6Dtte06R9BN37gd/g BRPNZHah2rdaUG2rAmsI+hZtylLKuzeRAPCMWM/Gcfsmou2sYldchCdAFVGt02iWD0UH3dKs 7DVQey0vPE533rCwZu57bWOh1UogoXr+68G6IBQO5HQYLMNi8nCnigJ07CXX+q/2W6LyuVMK vK+4WbDboEg41JAtRxmC5/PFz1Xj7JUJHQk9a3BuwEsNDk5xUIX0dEuETsQdZZGT4D1YmVsb 9foXaAJAKps2UyeYwV+4IpPDv9JDaXtJcPlhALxk2LMxyguH8GFbzAlabMPFJ8cMRHfP5zqS 9sEeL2w9OUkPeMkwm+/RVgmMPajJoCvN8Q2zXRL/eIRznb0vylMg62iSShxyJdVSjlLMY67c D8c1z2pjSBTfcesWRxSPOMU5FNX5ZyosKwv54GMT3ad+CS083kxs1bAxhRjqVX8GygbMqyre gRTOMEX+9v40Y3gm84fpYbrwL85fWo/etu+FE5vCUSzMM4ZwjxsbC1+0dwk6OD2MKBTTEaWC yGde0kSnlulPOQwsIoLoO/9/KBIAAAAAAAA= --------------ms010203070800090102060400-- From owner-freebsd-arm@freebsd.org Fri Jul 15 19:00:49 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04085B9A531 for ; Fri, 15 Jul 2016 19:00:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.chatusa.com (br1.CN84in.chatusa.com [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 8AEE81157; Fri, 15 Jul 2016 19:00:47 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: from pdx.rh.CN85.ChatUSA.com (localhost [127.0.0.1]) by pdx.rh.CN85.chatusa.com (8.13.3/8.13.3) with ESMTP id u6FJ0TkM069423; Fri, 15 Jul 2016 12:00:29 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.ChatUSA.com) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.ChatUSA.com (8.13.3/8.13.3/Submit) id u6FJ0HJG069422; Fri, 15 Jul 2016 12:00:17 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201607151900.u6FJ0HJG069422@pdx.rh.CN85.ChatUSA.com> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... In-Reply-To: <1468605794.72182.320.camel@freebsd.org> To: Ian Lepore Date: Fri, 15 Jul 2016 12:00:17 -0700 (PDT) CC: Paul Mather , freebsd-arm 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.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:00:49 -0000 > On Fri, 2016-07-15 at 10:29 -0700, Rodney W. Grimes wrote: > > [trimmed]] > > > > I'm having a hard time understanding how a problem report got > > > > generated > > > > about all this, or how any of it is anything other than "Karl > > > > misconfigured his system." > > > > > > > > The downloadable system images work correctly. You made a local > > > > change > > > > (formatted new media) and depending on how you want to look at > > > > it, > > > > either you didn't format correctly or you didn't make your config > > > > files > > > > match the way you formatted, and that made your system stop > > > > working. > > > > It doesn't mean there is anything wrong about the way the > > > > downloadable > > > > images are generated. > > > > > > > > Changing fstab in the distributed images so that a failure to > > > > mount a > > > > filesystem becomes a non-error seems like a bad idea to me. The > > > > only > > > > way that problem happens with a downloaded image is if the image > > > > wasn't > > > > burned successfully, and that doesn't seem like something that > > > > needs to > > > > just get papered over just because in your use-case you don't > > > > really > > > > need the filesystem that failed to mount. > > > > > > > > A PR about the fact that it hung without visibly reporting an > > > > error may > > > > be appropriate. A PR that says we should just paper over the > > > > error > > > > because you don't care about it doesn't seem appropriate. > > > > > > > > > Maybe it should be filed as a "feature request" rather than a > > > "bug." Does Bugzilla support the distinction? > > > > > > I agree with Ian that this is not a bug in the sense that anyone > > > installing from the distributed images will never trigger it on > > > their install media. > > > > So its not a bug because it doesnt happen at install time? Thanks, > > we can > > now go close 80% of the PR's as non bugs cause they dont happen in > > the > > install image. > > > > Excuse me? > > It's not a bug because: It's not a bug. Go download one of the rpi > snapshot or release images. Burn it. Boot it. It works. That only proves a tiny fraction of the caseses, again as I said if this proves that things are not a bug then lets go close 80% of our PR's cause this case does not trigger them. > Now go randomly change something. For example, reformat and repopulate > the card in a way that conflicts with what's in /etc/fstab, but don't > change fstab to match. Now it doesn't work. In your mind, that's a > bug? Yes, abosolutely, because the system failed in a way that appeared silent to the user, IE, the error message went to someplace other than where the user is going to be looking for it. As I said, we also need to create a PR that we dont tell the user to go hook a serial console up and look for failures when boot does not seem to be working. Spitting out most of boot time to vidconsole, then having /etc/rc output go someplace else is not an expected behavior. It ALSO failed for no real good solid compelling must have reason, just because a user MAY want to access the msdos after booting, it is NOT mandatory. Again robustness here. > A bug that should be fixed by changing fstab in our distributed > images to ignore failures to mount the filesystems contained in the > image? Certainly, if the system well operate without that file system, making it easier to repair what has gone wrong. Saving someone else from the hours of debug that Karl has spent tracking down what went wrong that would be what I would call an priceless improvement to the system. > I feel like I've woken up in bizzaro world today. > > -- Ian > > > > It is reasonable to file a feature request to omit /boot/msdos as a > > > mandatory mount. I think when I first was using FreeBSD/arm on my > > > Raspberry Pi it wasn't mounted, but then that predates the current > > > distribution images. Now it is. I can see arguments either way > > > and the current setting makes sense to me. I think Warner and Ian > > > hit the nail on the head that the real issue is the lack of output > > > on the video console during /etc/rc processing. > > > > > > > And that is, IMHO, a bug, and a PR should be opened for it as well. > > > > > Incidentally, does setting console="vidconsole" in > > > /boot/loader.conf fix the problem of a lack of /etc/rc messages for > > > those who are using an HDMI monitor as their primary/only console? > > > If so, there may also be a case for making that the default if the > > > assumption is that a minority of people will be using a serial > > > console. (Not a fair assumption right now, IMHO, but perhaps a > > > fair one going forward as FreeBSD/arm becomes Tier 1.) > > > > I think the issue of robustness inspite of problems is being ignored > > on these issues for > > some reason. Adding nofail to /etc/fstab makes the system far more > > robust in lite of > > things that may go wrong. This is a GOOD thing. > > > > Having console="vidconsole,comconsole" again is a robustness feature > > and makes handing > > install time, or any time later easier to deal with. > > > > Documenting that the output of /etc/rc.d/* does not appear on the vid > > console and > > that you should look on a serial console if you are experiencing boot > > time problems > > would be another robustness feature. > > > > Putting noatime, or atleast giving the user an option to, at FreeBSD > > install time > > on all SD card mounted file systems would be yet another robustness > > feature. I > > know that this is hard to do as the SD images are pre rolled with a > > hardcoded > > /etc/fstab at build time. > > > > FreeBSD should always strive to be robust inspite of problems, any > > problem, if > > the cost to do so is minimal. Adding nofail to the msdos partition > > fstab > > entry on the built images is a minimal effort. > > > > The tools that try to access this partition from userland well > > gravefully > > report errors that the user can easily address. > > > > My bike shed is Royal Blue. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Fri Jul 15 20:00:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A441BB9887D for ; Fri, 15 Jul 2016 20:00:23 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 56D331971; Fri, 15 Jul 2016 20:00:23 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id D17BCB76; Fri, 15 Jul 2016 16:00:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Paul Mather In-Reply-To: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> Date: Fri, 15 Jul 2016 16:00:18 -0400 Cc: Ian Lepore , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:00:23 -0000 On Jul 15, 2016, at 1:29 PM, Rodney W. Grimes = wrote: > [trimmed]] >>> I'm having a hard time understanding how a problem report got = generated >>> about all this, or how any of it is anything other than "Karl >>> misconfigured his system." >>>=20 >>> The downloadable system images work correctly. You made a local = change >>> (formatted new media) and depending on how you want to look at it, >>> either you didn't format correctly or you didn't make your config = files >>> match the way you formatted, and that made your system stop working.=20= >>> It doesn't mean there is anything wrong about the way the = downloadable >>> images are generated. >>>=20 >>> Changing fstab in the distributed images so that a failure to mount = a >>> filesystem becomes a non-error seems like a bad idea to me. The = only >>> way that problem happens with a downloaded image is if the image = wasn't >>> burned successfully, and that doesn't seem like something that needs = to >>> just get papered over just because in your use-case you don't really >>> need the filesystem that failed to mount. >>>=20 >>> A PR about the fact that it hung without visibly reporting an error = may >>> be appropriate. A PR that says we should just paper over the error >>> because you don't care about it doesn't seem appropriate. >>=20 >>=20 >> Maybe it should be filed as a "feature request" rather than a "bug." = Does Bugzilla support the distinction? >>=20 >> I agree with Ian that this is not a bug in the sense that anyone = installing from the distributed images will never trigger it on their = install media. >=20 > So its not a bug because it doesnt happen at install time? Thanks, we = can > now go close 80% of the PR's as non bugs cause they dont happen in the > install image. If you are being pedantic, I guess it is a sort of bug, of the class = PEBKAC. I don't believe FreeBSD can fix those. ;-) Note that what you said is not really what I said. I never said it = isn't a bug because you can't trigger it at install time. I said it's = not a bug because you can't trigger it on your install media. "Install = media" was probably a bad choice of words on my part. I should probably = have written "installed media." To clarify, I mean if you install via = the distribution image to an SD card then the resultant installed system = on that SD card will never trigger this "bug." Someone managed to have a problem because when they devised their own = method to make their own SD card that still used the stock distribution = /etc/fstab they omitted a vitally important step that caused the system = not to boot. I'm not sure how that makes it a bug with the distribution = images. If it is, I imagine the "How to reproduce" section would run = something like this: 1. Unlabel the MS-DOS file system on the MS-DOS partition of the SD card 2. Reboot your system 3. Become angry at your computer because it refuses to mount the MS-DOS = file system by its file system label ;-) >=20 >> It is reasonable to file a feature request to omit /boot/msdos as a = mandatory mount. I think when I first was using FreeBSD/arm on my = Raspberry Pi it wasn't mounted, but then that predates the current = distribution images. Now it is. I can see arguments either way and the = current setting makes sense to me. I think Warner and Ian hit the nail = on the head that the real issue is the lack of output on the video = console during /etc/rc processing. >>=20 >=20 > And that is, IMHO, a bug, and a PR should be opened for it as well. I agree, and because I also appear to have the same problem on my = FreeBSD/amd64 systems, I'm not holding my breath for a speedy = resolution. :-) (I've never managed to get "multicons" to work across all consoles = during /etc/rc.) >=20 >> Incidentally, does setting console=3D"vidconsole" in = /boot/loader.conf fix the problem of a lack of /etc/rc messages for = those who are using an HDMI monitor as their primary/only console? If = so, there may also be a case for making that the default if the = assumption is that a minority of people will be using a serial console. = (Not a fair assumption right now, IMHO, but perhaps a fair one going = forward as FreeBSD/arm becomes Tier 1.) >=20 > I think the issue of robustness inspite of problems is being ignored = on these issues for > some reason. Adding nofail to /etc/fstab makes the system far more = robust in lite of > things that may go wrong. This is a GOOD thing. >=20 > Having console=3D"vidconsole,comconsole" again is a robustness feature = and makes handing > install time, or any time later easier to deal with. >=20 > Documenting that the output of /etc/rc.d/* does not appear on the vid = console and > that you should look on a serial console if you are experiencing boot = time problems > would be another robustness feature. >=20 > Putting noatime, or atleast giving the user an option to, at FreeBSD = install time > on all SD card mounted file systems would be yet another robustness = feature. I > know that this is hard to do as the SD images are pre rolled with a = hardcoded > /etc/fstab at build time. >=20 > FreeBSD should always strive to be robust inspite of problems, any = problem, if > the cost to do so is minimal. Adding nofail to the msdos partition = fstab > entry on the built images is a minimal effort. >=20 > The tools that try to access this partition from userland well = gravefully > report errors that the user can easily address. I agree with most everything you say above. AFAIK, FreeBSD/arm = officially becomes "Tier 1" with 11.0-RELEASE. When that happens, I = figure "robustness" will be more at the forefront of development as it = becomes more mainstream due to that appellation. For me, all I can say is my hat is off to the FreeBSD/arm developers who = have improved the stability and usability of FreeBSD/arm just over the = last year. It has improved immensely. Thank you one and all! Cheers, Paul.= From owner-freebsd-arm@freebsd.org Fri Jul 15 20:10:57 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EED5B98BDD for ; Fri, 15 Jul 2016 20:10:57 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 DF3341F48 for ; Fri, 15 Jul 2016 20:10:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id CA3E244F82F for ; Fri, 15 Jul 2016 15:10:55 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm@freebsd.org References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> From: Karl Denninger Message-ID: Date: Fri, 15 Jul 2016 15:10:52 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090205020503070805080301" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:10:57 -0000 This is a cryptographically signed message in MIME format. --------------ms090205020503070805080301 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/15/2016 15:00, Paul Mather wrote: > > I agree with most everything you say above. AFAIK, FreeBSD/arm officia= lly becomes "Tier 1" with 11.0-RELEASE. When that happens, I figure "rob= ustness" will be more at the forefront of development as it becomes more = mainstream due to that appellation. Which was the point of the PR -- to improve robustness. Incidentally it appears (which I also posted on) that u-Boot has fixed the USB keyboard problem, but it's a bit more complex than it first appears to slot it for cross-compilation properly -- my first "cheap" attempt (grab it via git, run configure, see what you get) failed. Some attention ought to be put there for obvious reasons. > For me, all I can say is my hat is off to the FreeBSD/arm developers wh= o have improved the stability and usability of FreeBSD/arm just over the = last year. It has improved immensely. Thank you one and all! To put some parameters on this I have two PI2s that have *yet* to crash on 11-Current and that I recently rolled forward to 11-BETA1, which is how I got bit since I was trying to set up a "master" for that purpose. Those machines had been cranking along doing their jobs for upwards of three months and were last shut down for a code update. I've yet to see one blow up from other than a hard write error to the sd card. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090205020503070805080301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUyMDEwNTJaME8GCSqGSIb3DQEJBDFCBEAB mQGdqIg7Hivj3k5MfX+YTh08rmjRhtQjlEbvHIbvo7r+bYDjz3yN7oJD23g4Oxwcisv3egZq 5wRsTKWIJZ4eMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAhAo00eha CGXjzgf5R6jErQ18pzpxBgVYE+rUGi4efi+Sev1QrwY1dF2Yg/3XxrDEJh2ohZnUnORC03MY oDBrgTVaM1mziC6DX4dXSSzrtavFm0wduQ93DprqbHfQQ4FURxJF0xabEU3mn2JNUQTjuo+c kAUogikS5sgjpUNPBKeic+x8mHrYsDMM1I0AgvxVe7g3wEMRDGQ2VyFROdOuLBfCpYX5VLGl AbhJTGR5wOCDHkEQRSbTXItQKN5pVHGMc17tKfsSCXjtIrvD/yFyY+zXGhPaaTakgxvrIDoh bNtGJWYLFxuUWB4C7UF8wvTq1vyIUMdqcXf1g2wFwtFtDJytuvxkhdF+aSm7i5jv4SC0D+uZ 1CDnGRz9JRZ/f3jwYOSIbNW4lit8L2OHrlNBSMrDadQFBo6cWgL7lzjjMEraoyxhtdX421Qi blgHHly/7BBXXXMV3zgQw6EZBpq52ZLAJI9KkLpQRVulPvSijx93tvcMwNV+dy5xfkygl8PM wBDyBUVctiy66V0g6IVXYBAW0tUow2id5yYou7UzsLG5+k4JrMJVaiCouG5JSLsKnYwbsqXA GLJiQkC1+pg1bOD2FV3L+HT91STT2B6s2WW6PycOV5otD8XChIQB1JwG+8R5olH5GGARDI75 moAcNG00X0XbQc5r9c7QHn2/+O4AAAAAAAA= --------------ms090205020503070805080301-- From owner-freebsd-arm@freebsd.org Fri Jul 15 20:16:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41E69B98D1A for ; Fri, 15 Jul 2016 20:16:13 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EED4B12A4; Fri, 15 Jul 2016 20:16:12 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id j126so115953598vkg.3; Fri, 15 Jul 2016 13:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sGagNUT8hbdhA4t9eoanOIduXbVUNVtvYa1FbZYw1Js=; b=l3YigqoCWXnbmU2BhSb/Gwg1+37Tn6SBgByxS8gL6h8UjuwyK7Q8EXnjxSRTpK8yKq /FAmVh3cCatNR3V2m51TRCkhz+Y0JTXMFmCSM2OYe3nyua7eiQVFMT2cj07FqyGmxANW 0f2Vzf2gdookbHI/Ky9BFv9iPuTFnru0JikqsV0UmjZZQgYltqQ6vJu9quStVeEY+DrY lqmz35OHMC/35UXNaXoY5fPEGWTZ+po/6ktXluEn5+EquamMi/wezZ+xexljmOUtGsGz tCUfi35E4R9HQX+dwdncPFSmHKAixIZ6xHNqFvr30FIJbHEpkM5i2lwgJ3Yd3Lc1QIOL h2Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sGagNUT8hbdhA4t9eoanOIduXbVUNVtvYa1FbZYw1Js=; b=iHEAhWsj5y8DHMae5wG4e0L5mSuC8WNAE8qmCK45M8jo3lCGiYSnpCTdQrPn31vOwd erPh93pGyLPOnce/X1pQtyNxeGF9ekdwYM1mFDSeCegxiQnGq0mjkl9j2WbALF/etBje Iu0c6Mx4KZS99DnYMf3F0Xaptf1J243kWNya1akQNepG++O40rsi399sXM2AS0x6oxqa gqvp2ez5gzNRp1SKHQa4SIAsRp/BsctnZguJiBYyhD6iEGOwx7zyN0bulBsl7N5V+Kji ckW5Nzm9no73yIeK8g/ulVPlE+lgew/8p6BBZucZW8/zFas7e4W5Y5FGuDCfJn1UslO8 dzZg== X-Gm-Message-State: ALyK8tKUz5fNxmm/HYBPqcmITME/z2AZq+tnkV9td1bycHb8xBVjeN2rXvYGFGztN34bc4hY/1qwfaSJKHDLgg== X-Received: by 10.31.130.71 with SMTP id e68mr11451891vkd.145.1468613359333; Fri, 15 Jul 2016 13:09:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.54.75 with HTTP; Fri, 15 Jul 2016 13:09:18 -0700 (PDT) In-Reply-To: <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> From: Russell Haley Date: Fri, 15 Jul 2016 13:09:18 -0700 Message-ID: Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: Paul Mather Cc: "Rodney W. Grimes" , freebsd-arm , Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:16:13 -0000 Isn't putting an non-functioning embedded system on a serial console to debug standard procedure with ALL operating systems? It sure is with our embedded GNU/Linux products (even the ones with touch displays). I've pooched my SD cards lots of times (freebsd and GNU) and it's never generated this much interest. As far as continuing after a mount failure, my experience with lots of types of software (server, windows, embedded) is when a developer tries to handle exceptions he/she can't prevent, the whole thing just gets more messy. I sure want to know that the system ignored my u-boot variables when it booted and/or I can't use them to control the boot processes. Arm systems are embedded systems. In my experience they should halt and report an error to the lowest common denominator. In this case a serial console. While this is fast changing, the majority of arm deployments will not have a video console. Is there a can somewhere for my two bits? Russ On Fri, Jul 15, 2016 at 1:00 PM, Paul Mather wrot= e: > On Jul 15, 2016, at 1:29 PM, Rodney W. Grimes wrote: > >> [trimmed]] >>>> I'm having a hard time understanding how a problem report got generate= d >>>> about all this, or how any of it is anything other than "Karl >>>> misconfigured his system." >>>> >>>> The downloadable system images work correctly. You made a local chang= e >>>> (formatted new media) and depending on how you want to look at it, >>>> either you didn't format correctly or you didn't make your config file= s >>>> match the way you formatted, and that made your system stop working. >>>> It doesn't mean there is anything wrong about the way the downloadable >>>> images are generated. >>>> >>>> Changing fstab in the distributed images so that a failure to mount a >>>> filesystem becomes a non-error seems like a bad idea to me. The only >>>> way that problem happens with a downloaded image is if the image wasn'= t >>>> burned successfully, and that doesn't seem like something that needs t= o >>>> just get papered over just because in your use-case you don't really >>>> need the filesystem that failed to mount. >>>> >>>> A PR about the fact that it hung without visibly reporting an error ma= y >>>> be appropriate. A PR that says we should just paper over the error >>>> because you don't care about it doesn't seem appropriate. >>> >>> >>> Maybe it should be filed as a "feature request" rather than a "bug." D= oes Bugzilla support the distinction? >>> >>> I agree with Ian that this is not a bug in the sense that anyone instal= ling from the distributed images will never trigger it on their install med= ia. >> >> So its not a bug because it doesnt happen at install time? Thanks, we c= an >> now go close 80% of the PR's as non bugs cause they dont happen in the >> install image. > > > If you are being pedantic, I guess it is a sort of bug, of the class PEBK= AC. I don't believe FreeBSD can fix those. ;-) > > Note that what you said is not really what I said. I never said it isn't= a bug because you can't trigger it at install time. I said it's not a bug= because you can't trigger it on your install media. "Install media" was p= robably a bad choice of words on my part. I should probably have written "= installed media." To clarify, I mean if you install via the distribution i= mage to an SD card then the resultant installed system on that SD card will= never trigger this "bug." > > Someone managed to have a problem because when they devised their own met= hod to make their own SD card that still used the stock distribution /etc/f= stab they omitted a vitally important step that caused the system not to bo= ot. I'm not sure how that makes it a bug with the distribution images. If= it is, I imagine the "How to reproduce" section would run something like t= his: > > 1. Unlabel the MS-DOS file system on the MS-DOS partition of the SD card > 2. Reboot your system > 3. Become angry at your computer because it refuses to mount the MS-DOS f= ile system by its file system label > > ;-) > >> >>> It is reasonable to file a feature request to omit /boot/msdos as a man= datory mount. I think when I first was using FreeBSD/arm on my Raspberry P= i it wasn't mounted, but then that predates the current distribution images= . Now it is. I can see arguments either way and the current setting makes= sense to me. I think Warner and Ian hit the nail on the head that the rea= l issue is the lack of output on the video console during /etc/rc processin= g. >>> >> >> And that is, IMHO, a bug, and a PR should be opened for it as well. > > > I agree, and because I also appear to have the same problem on my FreeBSD= /amd64 systems, I'm not holding my breath for a speedy resolution. :-) > > (I've never managed to get "multicons" to work across all consoles during= /etc/rc.) > > >> >>> Incidentally, does setting console=3D"vidconsole" in /boot/loader.conf = fix the problem of a lack of /etc/rc messages for those who are using an HD= MI monitor as their primary/only console? If so, there may also be a case = for making that the default if the assumption is that a minority of people = will be using a serial console. (Not a fair assumption right now, IMHO, bu= t perhaps a fair one going forward as FreeBSD/arm becomes Tier 1.) >> >> I think the issue of robustness inspite of problems is being ignored on = these issues for >> some reason. Adding nofail to /etc/fstab makes the system far more robu= st in lite of >> things that may go wrong. This is a GOOD thing. >> >> Having console=3D"vidconsole,comconsole" again is a robustness feature a= nd makes handing >> install time, or any time later easier to deal with. >> >> Documenting that the output of /etc/rc.d/* does not appear on the vid co= nsole and >> that you should look on a serial console if you are experiencing boot ti= me problems >> would be another robustness feature. >> >> Putting noatime, or atleast giving the user an option to, at FreeBSD ins= tall time >> on all SD card mounted file systems would be yet another robustness feat= ure. I >> know that this is hard to do as the SD images are pre rolled with a hard= coded >> /etc/fstab at build time. >> >> FreeBSD should always strive to be robust inspite of problems, any probl= em, if >> the cost to do so is minimal. Adding nofail to the msdos partition fsta= b >> entry on the built images is a minimal effort. >> >> The tools that try to access this partition from userland well gravefull= y >> report errors that the user can easily address. > > > I agree with most everything you say above. AFAIK, FreeBSD/arm officiall= y becomes "Tier 1" with 11.0-RELEASE. When that happens, I figure "robustn= ess" will be more at the forefront of development as it becomes more mainst= ream due to that appellation. > > For me, all I can say is my hat is off to the FreeBSD/arm developers who = have improved the stability and usability of FreeBSD/arm just over the last= year. It has improved immensely. Thank you one and all! > > Cheers, > > Paul. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Jul 15 21:03:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E98AFB99C40 for ; Fri, 15 Jul 2016 21:03:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 98A2F11D3 for ; Fri, 15 Jul 2016 21:03:47 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id B1E3344FC44 for ; Fri, 15 Jul 2016 16:03:46 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm@freebsd.org References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> From: Karl Denninger Message-ID: Date: Fri, 15 Jul 2016 16:03:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040107000004070306000909" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 21:03:49 -0000 This is a cryptographically signed message in MIME format. --------------ms040107000004070306000909 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As an aside the new u-boot *does* speak to a USB keyboard out-of-box. I am going to attempt to build the environment in boot.scr, which should work (since it reads THAT as well off the boot media) -- if that works it obviates the need for a specific compilation for FreeBSD in the port. Needless to say that's a fairly-material win if it works. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040107000004070306000909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUyMTAzNDRaME8GCSqGSIb3DQEJBDFCBEC3 oAxQQ7REX+tXVSEI63Ilk0WfrQ8r2s5fImcgXiSkIoLr/IDxCS+g+kRw4JPdIgAdYOPWqi5B 2gh93RLdp5EoMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAmj7ttFo2 CNCd5ZB6TLPfCUsMSxAVmfJx5wJe2OAokFM6TXoLXEo21tbgCKIQH7LKT/8HHTEG90fCl7Ds Px4UcSHVTCFUapC0iaFmEE22E/oTXU6UoKZWWFnNPkOgBSc/YJZ4lLDdsmbGRNBsWOM/gqoB nRSJxYgnPum08zUAD2Ymd1IB1cLW1Ot/OzaoX5aMMK9Hk22RossfGU6z1bZ8PcWQMVP5Cvj/ jn0GbllXE101EyFHNKfEvvvKlcKeWkq7rLrlPDTCx0JzbvSAdhyMg3DZf9eOAtmsu9jEKmn0 1NRYxEp5FxbpgqURnagd1wkcs/E7eBxgdrcHApRbLCoO6Qm89Ik5Pr3xCzxq+eOt4bMYJaJj FDC4wMwGibuoWKXer/Wtj2yZ+WidDgIciMJJPccfJ8zoVd225bltQgkvUoBOQ4VX96co/5br qY7bVUMfFa3HRSRduh8ELAk26bIfhdDvNNLHymP5jpGaQZoxBTVriRceqDSYuY14XmJAyYqg gQYC10ThdKT6x5Q5kpPJoUv5nwvaRxQGJyIL8luTivFF1cN9u9/ps2PRQY9UArRQm6YhdJfe 9ODKH+q5u9CXrDCg4nGmUuG7J8+NCXVZYs/5C8hIs9j+ZYYphCNbSH1ouDgtpPyRiwDLZMTE q82f6gjLg6bjdlp82FLNb6iv9QcAAAAAAAA= --------------ms040107000004070306000909-- From owner-freebsd-arm@freebsd.org Fri Jul 15 21:18:00 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D66A9B99E66 for ; Fri, 15 Jul 2016 21:18:00 +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 201171668 for ; Fri, 15 Jul 2016 21:17:59 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9f5ef74b-4ad1-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 15 Jul 2016 21:18:05 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6FLHqLR009843; Fri, 15 Jul 2016 15:17:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468617472.72182.340.camel@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Ian Lepore To: Karl Denninger , freebsd-arm@freebsd.org Date: Fri, 15 Jul 2016 15:17:52 -0600 In-Reply-To: References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 21:18:00 -0000 On Fri, 2016-07-15 at 16:03 -0500, Karl Denninger wrote: > As an aside the new u-boot *does* speak to a USB keyboard out-of-box. > > I am going to attempt to build the environment in boot.scr, which > should > work (since it reads THAT as well off the boot media) -- if that > works > it obviates the need for a specific compilation for FreeBSD in the > port. > > Needless to say that's a fairly-material win if it works. > FreeBSD needs a build of u-boot that adds the CONFIG_API option so that loader(8) works. From what I've heard, recent versions of u-boot have broken the CONFIG_API option as part of the "device model" work. So a u-boot new enough that usb keyboards work on rpi is probably too new to work with our need for CONFIG_API. Our path forward probably involves abandoning CONFIG_API (since they seem disinclined to support it) and using the new EFI support u-boot provides. But we don't have an EFI loader for armv6 yet either (and I don't know that anybody has worked on that yet). -- Ian From owner-freebsd-arm@freebsd.org Fri Jul 15 21:29:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CBA6B9A0AE for ; Fri, 15 Jul 2016 21:29:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (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 D55A61ACD for ; Fri, 15 Jul 2016 21:29:55 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 9E56C44FD61 for ; Fri, 15 Jul 2016 16:29:53 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm@freebsd.org References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> <1468617472.72182.340.camel@freebsd.org> From: Karl Denninger Message-ID: Date: Fri, 15 Jul 2016 16:29:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1468617472.72182.340.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080209080008080407040207" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 21:29:56 -0000 This is a cryptographically signed message in MIME format. --------------ms080209080008080407040207 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/15/2016 16:17, Ian Lepore wrote: > On Fri, 2016-07-15 at 16:03 -0500, Karl Denninger wrote: >> As an aside the new u-boot *does* speak to a USB keyboard out-of-box. >> >> I am going to attempt to build the environment in boot.scr, which >> should >> work (since it reads THAT as well off the boot media) -- if that >> works >> it obviates the need for a specific compilation for FreeBSD in the >> port. >> >> Needless to say that's a fairly-material win if it works. >> > FreeBSD needs a build of u-boot that adds the CONFIG_API option so that= > loader(8) works. From what I've heard, recent versions of u-boot have > broken the CONFIG_API option as part of the "device model" work. So a > u-boot new enough that usb keyboards work on rpi is probably too new to= > work with our need for CONFIG_API. > > Our path forward probably involves abandoning CONFIG_API (since they > seem disinclined to support it) and using the new EFI support u-boot > provides. But we don't have an EFI loader for armv6 yet either (and I > don't know that anybody has worked on that yet). > > -- Ian Well then, it's not as easy as it first looked, which might explain why trying to boot by hand using the new u-boot (which does come up and talk to me) are not bringing me success :) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080209080008080407040207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUyMTI5NTFaME8GCSqGSIb3DQEJBDFCBEDk q42h0zTLeroZQOsDYG/mz6Qnm6kCPc/3tQtpgFW8PignVWBkNaIpNBcRutKR0LuOVVDTHlDn 7BVnKRQJZm0HMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIADLD8KTMP gBzVS645Cz2lcKcyeJnzbA1VeFbHq1gwOVOhKrf3DSWv8vSGhNC69CZY8yWvWiPnpJDjUOdc 0SsZfoUn7k96fBM4zK1ixni2wWSE+hS+NDaZ/RlEwmNXrflur8pFySr5WavA9lhw+4RkeTjW fDI4tH1hTmCLAURFU/Pt/IiSKmNTtdsvbdYP6h3iQMbwChjisrTq/8dudCpTv6aKhMHwkrJ9 yDGUytnfmXMgBIkPDDrLwTDmhgK0U1NjJhZYumzK2m+NFB00BdKDYfn60jOIkyw5paWz6cFJ 6loDoKg15mhvLsNdnIuIGg+XI1Mgl7GRWxZ5qjy37PLOvzdXXEQywbJAeR+R9841X6xF0BfI bE4y/qpRTKqB5fUo85SUz4Dy+RiboXCUz1NlQ3FQFbzvGs4nVhBzY86SMpD5yISUs6aOURni QMzDDVpflaA+P8RM1rvdiTMxmLStwLc5dA8p43bjLE/sI49Xt9hTdc+Ztbk9Xc7JjcZ5AcJw NVrPRw9O6Qe52aPxnncX5Wxv0lBIF+1OQuG07qjD/CtqZRn61GuXzcCjvV4OV8yminZJzeCf rRkgvREpj8+sAsw9Z5Db5OnC9e0GX0t4Gtbt6TENIUu2xtZChtKHv6Ac1ydho6fDX8YBQuRk NkU1yWFUXdsOQkCaQcQ6epW1lE8AAAAAAAA= --------------ms080209080008080407040207-- From owner-freebsd-arm@freebsd.org Fri Jul 15 21:57:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6DF8B9A6B3 for ; Fri, 15 Jul 2016 21:57:01 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id BEEC917F5 for ; Fri, 15 Jul 2016 21:56:57 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 1E399406063; Fri, 15 Jul 2016 14:47:52 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Russell Haley cc: freebsd-arm , hmurray@megapathdsl.net From: Hal Murray Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... In-Reply-To: Message from Russell Haley of "Fri, 15 Jul 2016 13:09:18 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jul 2016 14:47:52 -0700 Message-Id: <20160715214752.1E399406063@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 21:57:01 -0000 russ.haley@gmail.com said: > Isn't putting an non-functioning embedded system on a serial console to > debug standard procedure with ALL operating systems? My two cents... I have several Pi-s and I didn't use the serial port to get any of them going. I think the answer to your question probably depends on the maturity of the system and the hardware available. If a system supports a keyboard and display, that's what I would try first since I usually have one handy. I have a 4 port KVM box. The 4th port moves to the current project as needed. I have adapters handy so it connects to almost anything... After I get the network going, I just ssh in. (after a while, the KVM cable moves on to the next project) I think work to get early console output on the display and input from the keyboard will be an important step in making a user-friendly environment. I have the hardware gizmo for a serial console on the Pi. I'd get it out to debug something if the documentation (or email) clearly stated that was the right approach. I probably wouldn't think to try it without a reminder. I've don't plenty of low-level debugging. The serial port just wouldn't occur to me when working on a system that supports a keyboard and display. -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Sat Jul 16 00:13:21 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87D3DB9AA81 for ; Sat, 16 Jul 2016 00:13:21 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 4E6DC1F37 for ; Sat, 16 Jul 2016 00:13:21 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-it0-x236.google.com with SMTP id f6so31957847ith.0 for ; Fri, 15 Jul 2016 17:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to; bh=nsB2YkFMHZomOCWV6GECuJQWdTZo9CnzMz+Q5BiO9xc=; b=G+AhbdfA7wx1Iax3N/cIu9rVNzmBjmLDeP/l727cJwiYvZsxu6hwqmNsPHsy5tt2Vg 7v/4E9K2klWA5JBclbPZxRstMbBzIjIuLE9LrUPw6htpgVh+UX/w/rx7J63+JUclW6RB /1bj8smrkvIEwTdbBVJZSFAKGyiNpZdywLQ6u651I35qkkSsNBa18BuHA+Ca6vDNiPKc js/Vy81jGHMVILj/jffFc6yOuHbqa926n8wNJkx+kJwfb5vbd8+BLxY+99UscqhWPCGk LnU5bFKYCPKAHfA9Os0dWfPkmIw9ulOUjYKMSec/hyNbEhMdbeLe/SsyrEfxh61Qm5kU 4hdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to; bh=nsB2YkFMHZomOCWV6GECuJQWdTZo9CnzMz+Q5BiO9xc=; b=htNVbESdQsy4eB3pSPlubS5oPnuR2NZCEWecxLd7tGoJosl2asJJK1LfwO9bc1A1Zl R5RDO314v/QRZte7+xkjMSU+450EHK0lUurkAOXe0yWOn8mjyEyhoRbMaETdUHrRspvD YcywNxOcabZI8Ep2qj//hgNfUr5oQk6Mhx5HWeeFPunV58j7+/EqAo8+nRX14jWpDkvk mIwPWcbAPjygep5NAEmZ5+OaFG1pvHlKHwfhejomvLkUf3eNP913MkcNV0XO2HrR57z0 8Z0v06G3UdLBqL2d7i5tqdTt3XHGwtFlDby7sorSJY8Hfp5+ARqvN+lpAQVo7RNqFQRc DeYA== X-Gm-Message-State: ALyK8tIKYYRtc3GScsILt9G8UgT1slzhH542XLG4eH9svcuyaZoQ8sIttbDLqg5Po7YlUQ== X-Received: by 10.36.69.205 with SMTP id c74mr38930732itd.47.1468628000485; Fri, 15 Jul 2016 17:13:20 -0700 (PDT) Received: from [127.0.0.1] ([207.228.78.53]) by smtp.gmail.com with ESMTPSA id h99sm4322936iod.9.2016.07.15.17.13.19 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jul 2016 17:13:19 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160716001319.4743251.19447.8559@gmail.com> Date: Fri, 15 Jul 2016 17:13:19 -0700 Subject: Fw: Bizarre clone attempt failures on Raspberry Pi2... From: Russell Haley In-Reply-To: References: <20160715214752.1E399406063@ip-64-139-1-69.sjc.megapath.net> To: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 00:13:21 -0000 Sorry, did Cc everyone... Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the=A0Koodo=A0networ= k. =A0 Original Message =A0 From: Russell Haley Sent: Friday, July 15, 2016 3:13 PM To: Hal Murray Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... On Fri, Jul 15, 2016 at 2:47 PM, Hal Murray wrote: > > russ.haley@gmail.com said: >> Isn't putting an non-functioning embedded system on a serial console to >> debug standard procedure with ALL operating systems? > > My two cents... > > I have several Pi-s and I didn't use the serial port to get any of them g= oing. That's because you didn't have any boot issues. Debian, BuildRoot, FreeBSD, and even MINIX 3 on Freescale iMX53, Freescale iMX6 and Begal Bone Black will all halt if there is an error in the boot process and force you to go to a serial console (Raspian has a video out I think). The first question from a hardware engineer working on a board/BSP will be, "What do you get in the serial console"? > I think the answer to your question probably depends on the maturity of t= he > system and the hardware available. If a system supports a keyboard and > display, that's what I would try first since I usually have one handy. I > have a 4 port KVM box. The 4th port moves to the current project as neede= d. > I have adapters handy so it connects to almost anything... After I get the > network going, I just ssh in. (after a while, the KVM cable moves on to t= he > next project) > > I think work to get early console output on the display and input from the > keyboard will be an important step in making a user-friendly environment. I'm not saying otherwise. I am saying in my experience that video output is probably not the expected outcome for the majority of developers working in embedded systems. Yes, that would be great but few systems will actually have a video out. Is it so important to support this use case in the RPi? I can't answer that. But what I can say is when I have asked questions like "why am I not getting any output?" or "why isn't my board booting?" the answer invariably has been: "Have you checked your serial output"? These answers have been from here on this mailing list, and from live hardware engineers. Cheers! Russ > I have the hardware gizmo for a serial console on the Pi. I'd get it out = to > debug something if the documentation (or email) clearly stated that was t= he > right approach. I probably wouldn't think to try it without a reminder. > I've don't plenty of low-level debugging. The serial port just wouldn't > occur to me when working on a system that supports a keyboard and display. > > > -- > These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Sat Jul 16 05:47:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3C2CB99183 for ; Sat, 16 Jul 2016 05:47:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 B140D1690 for ; Sat, 16 Jul 2016 05:47:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x242.google.com with SMTP id y195so7596964iod.0 for ; Fri, 15 Jul 2016 22:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AK2sJMcSXb9SOCsgN+9k22zIMLcBdGTCe3MGTc4hk74=; b=depxpZnh2dEWxNAsasESQPsTk6IWUgcnh7tpZ+QK8+VSCMA5KvQmkU3vd7Mc4W7QHU +coEuQUtCYopds8QEPYY9JvLvRb8nDrxs29I1z2wzhhjsGJG6vs/Hmi5xiqqSHDqUo0t ixeu/ClxIloffeTno92zYMqAfN+6vTEIrVenpd2plglzpIjb1SoAMh7QClzR76FTrfmy qV72eMCr6AvaQ3NQCJHHkf2H6k4ffnuZptl9uIimdCImC0xgspXCVAToKuczDsnANbyz CkNiy+fz9aP+5HkZdgS6HNbVyIk2Ahf8Nxu4sX6+f8M9VYMh0gXIFqcaeYbrimvr1jzD HhqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AK2sJMcSXb9SOCsgN+9k22zIMLcBdGTCe3MGTc4hk74=; b=NI8owWnmFS/w56pAJm8iWg79AmbDX2EBAAh8hxYnltCpRaLR5Fwis24eRQJqDWnWkG KmH1K7peXpCIpbsUAZtBOgtWSAsAtpJiS/JpYyLHmaGNNTuhlI6PpVlFN9mkgn7xDvWz Czn6m96gd5ZrC/YofzMJMdx3NAQUAH6GtQsP6MSWP1/xTbhZ9Bz5z834rGSBZhgHk9YO qvtthWo/MW4O6ksxnEp2uFVpEHFxVdOz3IuCO5pKzNtzFbvADRhCNPXkXCx4xCBa5r4I 3bICpreI7MkcvL5zWuL+ddZA4j/ygTF1dT7b3ZvfeLy/7eQTruKzHbxjnSjDOCUlgQWw dOxA== X-Gm-Message-State: ALyK8tLsMc5LhsmI7wJv3RuD1IsYejYGmoxEE2s+9yN9nxuCziDl3vVWChDeSIGHDvFJQheVMjCROJ6WGlldYQ== X-Received: by 10.107.144.10 with SMTP id s10mr23814534iod.165.1468648053108; Fri, 15 Jul 2016 22:47:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Fri, 15 Jul 2016 22:47:32 -0700 (PDT) In-Reply-To: <681626.83208.qm@web101715.mail.ssk.yahoo.co.jp> References: <681626.83208.qm@web101715.mail.ssk.yahoo.co.jp> From: Adrian Chadd Date: Fri, 15 Jul 2016 22:47:32 -0700 Message-ID: Subject: Re: RT1310 support To: Mori Hiroki Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 05:47:34 -0000 ooo nice! can you put together a patch in reviews.freebsd.org ? I'll look at it and commit it if everyone is happy! (Same with the AR24xx/54xx SoC stuff too, I'd like to see that.. :) -adrian On 11 July 2016 at 15:23, Mori Hiroki wrote: > Hi > > This is Ralink old arm soc RT1310A support code. > > https://github.com/yamori813/freebsd/tree/zrouter/sys/arm/ralink > > > dmesg is here. > > https://gist.github.com/yamori813/88224f1c96c9c592fb611b12a15e4ab5 > > > I like old soc. :) > > Hiroki Mori > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"