From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 19:25:00 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D0FE732; Wed, 21 Jan 2015 19:25:00 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4668C5; Wed, 21 Jan 2015 19:24:59 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id fb4so30553205wid.2; Wed, 21 Jan 2015 11:24:58 -0800 (PST) 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=kJ/g2KBX8Zfw6QOqolF8Kby7Y/ez22TIOFKe/Nzo4jI=; b=H585P/dn0nI8rIAy181eeDpTzWNUEWKLuaLBojxZPyNsUTEYQh4v2nyBWNAJSBtKHf MhYEeh95/wreaph0mOBFZiBqacM41I1fs0ku6jmHxOnrwxDiZGsw4IRc8W17GXKCrLEP pSTUB+qkFGCl4UyxbQRHB6scZwnfCNdU/kabbySg3j759FhNVdIQZTPWuup/ea2WBv8l KptfgwEDhQHB6q5Gkmf8+W3x8SLhIl5rmHYvYuyn+mf7C+Bp0H/lOI8XeEwCFxPAJ0I4 m1OZ2q/B04JYqWoGw9pBZ4s8bDF+Bqb9skXscF5iIeuGbYWEW+b0bVjAx0HHRIZKR1Ar O8ug== MIME-Version: 1.0 X-Received: by 10.194.77.97 with SMTP id r1mr28945655wjw.51.1421868298224; Wed, 21 Jan 2015 11:24:58 -0800 (PST) Received: by 10.216.213.145 with HTTP; Wed, 21 Jan 2015 11:24:58 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Jan 2015 17:24:58 -0200 Message-ID: Subject: Re: Raspberry Pi stability improved From: Luiz Otavio O Souza To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 19:25:00 -0000 On 18 January 2015 at 19:41, Warner Losh wrote: > >> On Jan 18, 2015, at 11:29 AM, Michael Tuexen wrote: >> >> On 18 Jan 2015, at 16:51, Daisuke Aoyama wrote: >>> >>> Hi Michael, >>> >>> Did you use /etc/rc.d/autosize ("option AutoSize" in crochet-freebsd)? >> No, I used (for a year or so) the script from >> git://github.com/daveish/freebsd-arm-tools.git >> and did a manual resize after the system got up. > > If you reside with gpart, you may hit a frustratingly stupid gpart bug. > > We tell a lie about the CHS of the SD cards. This lie works its way into = the alignment of the partitions. > The md and da devices also lie about the CHS of SD cards. They tell diffe= rent lies (and often times > different USB adapters tell different lies) so that screws up gpart. It a= ssumes that the CHS is The Truth > and The One True Way to create partitions is to have them cylinder group = sized and aligned, even when > resizing an existing partition. However, since the CHS is a lie, and nobo= dy can get their story straight, > gpart expresses its displeasure by starting the partition at a new locati= on, effectively killing your > filesystem which now starts at the wrong place on the disk... > > That=E2=80=99s what=E2=80=99s killing the autoresize. :( Sadly, I have no= fix for this, but it is a problem I hit about 6-9 months > ago=E2=80=A6 I talked about the problem then, but I can=E2=80=99t recall = if it was on a public mailing list or just private > email to part=E2=80=99s author. geom_part_bsd also fails to recognise a valid bsd partition scheme at eMMC of beaglebone-black: # gpart show =3D> 1024 3750912 mmcsd0 MBR (1.8G) 1024 4096 1 !12 [active] (2.0M) 5120 3072 - free - (1.5M) 8192 3735552 2 freebsd (1.8G) 3743744 8192 - free - (4.0M) =3D> 0 3735552 mmcsd0s2 BSD (1.8G) 0 3734528 1 freebsd-ufs (1.8G) 3734528 1024 - free - (512K) that's because geom_bsd_part can't 'believe' in sectors > 255: 407 sectors =3D le32dec(buf + 44); 408 if (sectors < 1 || sectors > 255) 409 goto invalid_label; And the lie we are pushing on this particular eMMC device says it has 1024 sectors! Geom name: mmcsd0 Providers: 1. Name: mmcsd0 Mediasize: 1920991232 (1.8G) Sectorsize: 512 Stripesize: 524288 Stripeoffset: 0 Mode: r2w2e5 descr: MMC MMC02G 3.10 SN 3026BC54 MFG 12/2012 by 254 0x004e ident: 3026BC54 fwsectors: 1024 fwheads: 183 If 1024 sectors cannot represent a valid geometry then we should tell a better lie here (or at least make the other parts of the system believe in our own lies). Luiz