Date: Thu, 28 Aug 2014 13:06:21 -0700 From: Warner Losh <imp@bsdimp.com> To: Stacey Son <sson@FreeBSD.org> Cc: freebsd-mips@freebsd.org Subject: Re: FreeBSD 10.0-STABLE on EdgeRouter Lite notes/issues Message-ID: <89108FE4-59E2-471B-AF9D-AAAA9E02A4B0@bsdimp.com> In-Reply-To: <FF7542EA-B008-448B-84DF-CB6F21F10A22@FreeBSD.org> References: <CAL8FB_0PJJQupX9Ekz=6L_rUo5Jr0J=xYO0Knb%2B_o5yf9ruYJg@mail.gmail.com> <FF7542EA-B008-448B-84DF-CB6F21F10A22@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_5550EDE6-0281-4650-AF51-79F9A78CD6F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 28, 2014, at 12:59 PM, Stacey Son <sson@FreeBSD.org> wrote: > Hi Sean: >=20 > Some answers to your questions are inline below... >=20 > On Aug 24, 2014, at 4:23 PM, Sean Hamilton <seanhamilton@gmail.com> = wrote: >=20 >> Running 10.0-STABLE r270425 on an EdgeRouter Lite. >>=20 >> "makefs -B big -o version=3D2" seems to produce a broken image which >> cannot be mounted read/write. See misc/162503, bin/188762. FS >> performance on USB flash is awful without softupdates, so UFS2 is >> effectively mandatory. I built a rescue-only mfsroot and newfs'd and >> untar'd the real system from there. Flash performance still isn't >> great, but it is tolerable. Mounting noatime helps. Were it not for >> the makefs bug, this process would be much easier. >>=20 >> Attempting to makefs directly onto the USB flash is painfully slow -- >> writing a file, then dd'ing that to the device is much faster. I >> assume makefs does a lot of small writes. Can the OS cache and = combine >> these? It would also be nice if makefs could detect the size of the >> target device and set the FS size and number of inodes appropriately. >> Of course at that point it's basically newfs. >=20 >=20 > The way I do it is create a FS only the size that is needed and 'dd' = to USB then 'growfs' later.=20 >=20 > Nathan Dorfman's script makes it easy to make images... >=20 > http://rtfm.net/FreeBSD/ERL/mkerlimage >=20 > You may have also have seen his webpage on the ERL: >=20 > http://rtfm.net/FreeBSD/ERL >=20 >> Also for some reason, ERL u-boot's tftpboot seems to refuse to talk = to >> FreeBSD's tftpd, so I had to copy my rescue-only image to the flash. = I >> didn't investigate this closely, could be operator error. >>=20 >> Any suggestions for VFS tuning on ERL? Ideally the OS could >> aggressively cache filesystem writes, then lazily write them out >> asynchronously. Would softupdate journaling be of any benefit? >>=20 >> gpart insists on aligning MBR partitions to cylinder boundaries, and >> seemingly ignores -a. Is there some way to prevent this? If not, can >> it be fooled by overriding the disk geometry? I'm not sure how much >> this matters on USB flash devices, but it matters a lot on SSDs. I >> wound up partitioning with GNU parted, since it does what it's told. >>=20 >> I would prefer to use GPT, but it seems like ERL u-boot doesn't >> support it. Another option might be to use GPT, create a freebsd-boot >> partition, dd the kernel directly there, then just load the sectors >> directly with u-boot, bypassing the filesystem entirely. >=20 > Yeah, the ERL u-boot seems kind of simple. You may have noticed that = 'mkerlimage' puts /boot in a FAT partition. Once the kernel is loaded = you can do about any partitioning scheme you want. IDK. It would be = nice if the ERL had a second USB or some onboard flash that could be = used or something. >=20 >> Ports are totally unbuildable on ERL. This seems to be a toolchain >> problem. ports-mgmt/pkg (which everything depends on) fails to build >> with: >>=20 >> libtool: install: ranlib >> /usr/ports/ports-mgmt/pkg/work/stage/usr/local/lib/libpkg_static.a >> ranlib: fatal: Invalid filename >>=20 >> I imagine this relates to the recent freebsd-mips posts about strip >> corrupting static binaries. >=20 > Yes, this is most likely the 'strip' bug. See = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191587 for the = details. The workaround is to not strip static libraries. >=20 > FYI, you can find some ports I have built for FreeBSD/mips64 (using = qemu user-mode) at: >=20 > http://www.cl.cam.ac.uk/research/security/ctsrd/mips64-packages/ >=20 > Sean Bruno may even have more some place. >=20 >> tcpdump is broken, as the packet lengths it reports are incorrect, = and >> it eventually segfaults. I thought this might be an issue with the >> octe driver, but it seems even the loopback device is afflicted, so >> perhaps it's an endianness issue? >=20 > You should file a bugzilla bug report especially if you have a packet = trace that can be used to easily reproduce the problem. >=20 >> Regarding https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D177876 = -- >> is this patch still a good idea? Or has it been merged? >=20 > I have been using it for some time. If you plan on mounting and using = NFS volumes or anything else the might take a lot of kernel thread stack = space then it is a good idea. >=20 > A better version of this patch (that moves the mips dependent code out = of the vm layer) has been merged into a MIPS64 FreeBSD project and that = code will be upstreamed sometime in the near future. You can find the = changes here: >=20 > = https://github.com/CTSRD-CHERI/cheribsd/commit/b39bec2cefe36293ffb2322969c= 9f7c9cae8c1a2 >=20 > = https://github.com/CTSRD-CHERI/cheribsd/commit/04ea99d04f6d5a595be759d34e8= 4e7fd9cea8166 I don=92t suppose this could be done w/o adding #ifdef __mips__ to = vm_glue? No need to block upstreaming on this, but it seems this could = be a MD routine instead... > = https://github.com/CTSRD-CHERI/cheribsd/commit/ae4f8d84bc30ffe2b2698534a2e= 6ab64480e8432 On the whole, I really like this, but was hoping it would be cleaner. = There=92s a crying need for it=85 Warner > For now, I would just used the kernel patch at: >=20 > https://people.freebsd.org/~sson/mips/kstack/kstack_large_page.diff >=20 >> Is there an estimate as to how many people are running FreeBSD on = ERL? >> Many thanks in advance for suggestions on any of the above! >=20 > Good question. I know of three or so. >=20 > -stacey. >=20 > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to = "freebsd-mips-unsubscribe@freebsd.org" --Apple-Mail=_5550EDE6-0281-4650-AF51-79F9A78CD6F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT/4u9AAoJEGwc0Sh9sBEAYpEQANZ4SwCjDLbfGdbMYER9CDfe jDDCkbi3lU/P1UP1l9/m/X8/k5GKPeAxMKYN+gJGB0zwY3rY53wneC4EoiChbAK0 hAEpE3jtWBQ/JOKIsHpwfJK28sE4eZsaKN8LZq+8uFOD+XIFdzDa3Mav/iGQgXur VOcyp0yOYB7pOLY+2PVYAWS3iEOdON014vc0yWo+9KsE0LsDDQI/o1LW6CLkW/XN TgAIKjW3tLWFWwTmolmMp1u8UHlfIup6VcWrlwVNzshCFe907lHAxi9EaYrhKHLM ctyLCktEGvv5SLy0Yz5agL+Y21SP8VRpcK6EAfHrGWbPOhSReX7kgNTb9ILDJzVF x6kXiRltQm277MfVufJV9U5VezRM0mkaTPVaBJDkEcEtq03VzYHMyDF/9vKV7zmY XpEyMqZsj3E4RAD0lTTIYurMfcUyaK8ucajMKbrJuSlbV6m+yvaw3MdvGM0BZWgY 0V2okHLUZTC4zdvWNdJYPM7iKOmXrSp67NuZt0eBcxnTbwwyVFROL8KfbFSiVhBc 8nb3f4j0xsXHJeZy0jaxq5+Fd2Uu2deXy6TKc/kDACdIQAaqv7saHyzBja+Lgiou N6Q4eA+h1WQPqfR+O9XoSXGB36xO6u0Pq1ccRUUikXixMx5FH/YY4rziMa+6u0yk lEAelYhX7rJT25hbzs55 =JcjS -----END PGP SIGNATURE----- --Apple-Mail=_5550EDE6-0281-4650-AF51-79F9A78CD6F0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89108FE4-59E2-471B-AF9D-AAAA9E02A4B0>