From owner-freebsd-arm@freebsd.org Tue Jun 26 06:25:38 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 410D4101340A for ; Tue, 26 Jun 2018 06:25:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA7EF81D67 for ; Tue, 26 Jun 2018 06:25:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id e15-v6so14873660iog.1 for ; Mon, 25 Jun 2018 23:25:37 -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; bh=EngMMXn/m+iq7P99duH/tA+xv3aaUnrM4A2ie3x7fe0=; b=jpi+wtfndSaA3eTCPyc1ZbDUoLnowTv80GZGiXyI2dzJvfHsYCEhIxp7X+zQPeqFgG Wk0kq5CxBzGSiAQcQki8fNYCntA//InI70ZIiYUQEu03Lzn+60V/r27+bMZuJfp2Za1S 6QZDunb7+TjEYoDXtQfFZP5u5Lm0jIzhz/5qVlYvuAx/hrmM1Bw7KJM+dsQ9p8nUc3rE mCtOEXj2yrEnxzIeH+7IIWH1PqNMM7ZVAvztRFcerSPHUIrLs87DKHJpSdE+1xacOEjv RUVu0RbujHJpoJVXKX8DwLFx8MI+UOuV0M7w/iTsMfvUl/BR5xnfkdHyglptOdk9pQLh qyLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EngMMXn/m+iq7P99duH/tA+xv3aaUnrM4A2ie3x7fe0=; b=YtSlJEiqXhYEy89krPLpX7v0LD687Aid39aEsEsjo5anSw5DvB9id2IeagcVd0Z9Mz +Ia0/BBVrKug/aMzszEC7nz0U0zveuIKX994FwrABpEE4GyLeE7tbBCn7h0XD8okIJjQ I1OxnacJdaM6yqx5cl5GYVR2JJFW9M2VgV8LfShaLz1lavIzha66od4kEdGj20bsaFFl +jEB9VI9oLKG21jnouGx5FAXyCQ7t/C1L9ucDjeVlC+ohHOLlQOqR7VAzO9Lpugra+cz q2gcuT5Q/l3rVDy0Kcd/SE5e1RinUIAiE/b0KOzV9QyYX+CFIo+RdU2CqRdgXdNuCKjS gI9A== X-Gm-Message-State: APt69E1gw6HUtxIoL2VWP6ubwNv1OT5OadGxIYSXmDXTYxq4W5ESZxjR FtHaJ96qi2fsZ3aL6CkR0ng5DwLhpBj/2MHnfWtWbw== X-Google-Smtp-Source: AAOMgpckFCf1k7Oazq/2yLnK1qQvOIugXNsQYH1voTpjPf0VwUhetKx8aFeDfdTuwmKjFL33WGu00o/fy7uSR1rS4PY= X-Received: by 2002:a6b:29c4:: with SMTP id p187-v6mr133088iop.299.1529994336956; Mon, 25 Jun 2018 23:25:36 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 23:25:36 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180626052451.GA17293@www.zefox.net> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> From: Warner Losh Date: Tue, 26 Jun 2018 00:25:36 -0600 X-Google-Sender-Auth: PhE_NW9NpiEELZ_OIS4yYM0T1ZE Message-ID: Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices To: bob prohaska Cc: Mark Millard , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 06:25:38 -0000 On Mon, Jun 25, 2018 at 11:24 PM, bob prohaska wrote: > On Sun, Jun 24, 2018 at 09:22:38PM -0700, Mark Millard wrote: > > On 2018-Jun-24, at 4:10 PM, bob prohaska wrote: > > > > > > > I've tried to replicate the RPi3 "run out of swap" experiment after > > > updating source, kernel and world to r335576. Roughly the same things > happen: > > > Errors flood the console, when swap usage goes a bit over 80% the > machine becomes > > > unresponsive. No sign of the OOM assassin. > > > > > > However, -j4 buildworld got all the way to building libraries. With > r334939 it > > > always stopped in cross tools. That seems like a significant > improvement > > > in swap usage efficiency. Is this to be expected? > > > > > > > >From the log file: > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/ > 1gbsdflash/buildworld.log > > > > is the text: > > > > --- buildworld --- > > make[1]: "/usr/src/Makefile.inc1" line 299: SYSTEM_COMPILER: Determined > that CC=cc matches the source tree. Not bootstrapping a cross-compiler. > > make[1]: "/usr/src/Makefile.inc1" line 304: SYSTEM_LINKER: Determined > that LD=ld matches the source tree. Not bootstrapping a cross-linker. > > > > So the cross compiler and cross linker were not built: the existing > > llvm files were used. > > > Ahh, so it wasn't a massive performance increase.... too bad! > > > > > What details were captured can be seen at > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/ > > > in case they're of interest. > > > > > > You are still using the drive that gets the errors ( /dev/da0 ), > > even if it is not being used for swapping. > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/console > > > > shows: > > > > _vfs_done():da0d[WRITE(offset=51819347968, length=131072)]error = 5 > > g_vfs_done():da0d[WRITE(offset=51819479040, length=28672)]error = 5 > > g_vfs_done():da0d[READ(offset=59586936832, length=32768)]error = 5 > > g_vfs_done():vm_fault: pager read error, pid 823 (tcsh) > The device is broken if you get this. Period. I don't know if it is hardware, or software, but it is not a reliable storage device. Until that's fixed, you'll continue to have a terrible experience with it. > Yes, I'm still using that same device. The errors attributed to /dev/da0 > were reported nearly two hours after the system first reported distress. > That makes it hard to believe the errors caused the problem. > da0 is broken is what these errors mean. Broken. Not a little under the weather, or pining for the fjords, but an ex parrot. Errr, a broken thumb drive, a broken driver, or a drive that's missing a quirk. Trying to assign which partition is broken misses the bigger picture: you shouldn't see error rates like this. That means something is wrong. I presume the drive isn't defective (though that should be ruled out by swapping in a similar thumb drive), which leaves missing quirk (the umass driver is doing something to make it go catatonic which we may have quirks for since you can't probe it), umass has some kind of bug, or the usb bridge on the rpi goes out to lunch. Sorry to sound so harsh, but the data has been consistent on this for everything you've reported: it works for a while, then we get a bunch of errors then a reboot. We need to start narrowing down which of these three broad classes of root causes it is. I'd rank actual bad thumbdrive last on the list. It's a tossup for me between missing quirk and a bug in the rpi usb driver that manifests itself only under heavy load. IIRC, you said one of rpi2/3 works and the other doesn't, which would suggest a usb bridge driver problem... Warner Warner