From owner-freebsd-mips@FreeBSD.ORG Thu Aug 28 20:46:24 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC131475; Thu, 28 Aug 2014 20:46:24 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A4F41E82; Thu, 28 Aug 2014 20:46:23 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so1573737lbv.10 for ; Thu, 28 Aug 2014 13:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S1AcgVVi935kdi3OxOcPZEz50cEBcuKDfWSYR0+8kbk=; b=CLSN48owQ+Ig63Oy4HZlr3P+2u0xe39EYCjQxKYPFlxL4U1zM0p3IQUqX5asaig7Fk /97rw8nSIGpMi+s49L3cWw02gx8y6Q3VflC4aexNMYkr+AFfcOLUjABRk8f+G8Vc/4Z6 pbZ5J3avBsgGaxhIk8kIpcFq/SAimEF3auvP1CZDRW2UgJTpCIHRX+k3DP2cucfBr/21 Fawv+egDor/NVUjDwGYDIlqN01YkNTcy+vpCmdDWCC8wbPNr4X6f+SdoV9TxxsIqc+H7 AKgsK7K2k3UxFKBK89gCD+oF4I9xpDAzL18TYAYCxZDW5FIjn6/aDsFzAodrQ5DB/k9b 5PDg== MIME-Version: 1.0 X-Received: by 10.112.28.8 with SMTP id x8mr5165766lbg.104.1409258781951; Thu, 28 Aug 2014 13:46:21 -0700 (PDT) Received: by 10.112.128.167 with HTTP; Thu, 28 Aug 2014 13:46:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Aug 2014 13:46:21 -0700 Message-ID: Subject: Re: FreeBSD 10.0-STABLE on EdgeRouter Lite notes/issues From: Sean Hamilton To: Stacey Son Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:46:25 -0000 On 28 August 2014 12:59, Stacey Son wrote: > Yeah, the ERL u-boot seems kind of simple. You may have noticed that 'mk= erlimage' 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= . The ERL does have 4 MB NOR flash for u-boot, and I'm guessing most of it is unused. You could surely put a kernel in there, if you could make it fit. I produced a fairly minimal kernel configuration and its .text is still >6MB, but the whole kernel xz's down to 1.8 MB, so there's hope. I'm not sure if the flash can be written from FreeBSD, though it can be written from u-boot. I think it makes more sense to just dd the kernel directly to the USB flash sans-filesystem, then use the "usb read" u-boot command to load it. Then you don't need to worry about bricking your ERL. >> I imagine this relates to the recent freebsd-mips posts about strip >> corrupting static binaries. > > Yes, this is most likely the 'strip' bug. See https://bugs.freebsd.org/b= ugzilla/show_bug.cgi?id=3D191587 for the details. The workaround is to not= strip static libraries. Building ports with INSTALL_TARGET=3Dinstall (instead of the default install-strip) seems to circumvent stripping for the most part. Building e.g. python27 still doesn't work, possibly due to the strip issue. I'll look into the strip bug if I can find time and nobody else is on it. Build performance on the ERL is tolerable, so long as you consider it to be a non-interactive process. Some builds seem like they are probably I/O bound, though I haven't actually measured. I'm still very interested in suggestions as to if/how FreeBSD can be made to cache and defer FS writes. I'm considering tmpfs and a rsync cronjob if it can't be done in the kernel. >> [ tcpdump problem ] > > You should file a bugzilla bug report especially if you have a packet tra= ce that can be used to easily reproduce the problem. The issue is trivial to reproduce. It doesn't seem to matter what the payload is -- it reports huge packet lengths (possibly byte swapped) and it quickly segfaults.