From owner-freebsd-arm@freebsd.org Tue Jun 26 07:01:15 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 33E8A101512C for ; Tue, 26 Jun 2018 07:01:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 978998306F for ; Tue, 26 Jun 2018 07:01:14 +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 w5Q71RX3018088 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jun 2018 00:01:28 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5Q71QfJ018087; Tue, 26 Jun 2018 00:01:26 -0700 (PDT) (envelope-from fbsd) Date: Tue, 26 Jun 2018 00:01:26 -0700 From: bob prohaska To: Warner Losh Cc: Mark Millard , "freebsd-arm@freebsd.org" Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180626070126.GB17293@www.zefox.net> References: <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> 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.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 07:01:15 -0000 On Tue, Jun 26, 2018 at 12:25:36AM -0600, Warner Losh wrote: > > > > > > _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. > > > > 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... > My references to rpi2 probably aren't meaningful; swap usage is about 10% of what happens on rpi3. All I can do is swap media. I think the easiest thing to try is dd the old da0 onto a second thumb drive. a second experiment is to set up a new boot microSD and thumb drive (same brand, model and size, slightly newer); basically setting up a new system. Which approach is apt to be more informative? Here's the dmesg output for the device and its potential successor: da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number 4C530001211014123270 da0: 40.000MB/s transfers da0: 59840MB (122552320 512 byte sectors) da0: quirks=0x2 da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: Removable Direct Access SPC-4 SCSI device da1: Serial Number AA010428162242131598 da1: 40.000MB/s transfers da1: 59836MB (122544516 512 byte sectors) da1: quirks=0x2 Thanks for reading, bob prohaska