Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jun 2018 00:01:26 -0700
From:      bob prohaska <fbsd@www.zefox.net>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Mark Millard <marklmi@yahoo.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices
Message-ID:  <20180626070126.GB17293@www.zefox.net>
In-Reply-To: <CANCZdfpXyzxzOZ8pqcRtuFsxYx5Jjs9oSL1ok2sGVPHdiB0qVQ@mail.gmail.com>
References:  <a232ed45-a9a9-1017-72ed-720a6c7a8f03@sentry.org> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <a2d7f4d3-0b6d-f82d-bae8-0988b0b54a8f@sentry.org> <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <C87C40CF-15B2-4137-892C-F2ADBAB32418@yahoo.com> <20180626052451.GA17293@www.zefox.net> <CANCZdfpXyzxzOZ8pqcRtuFsxYx5Jjs9oSL1ok2sGVPHdiB0qVQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <SanDisk Extreme 1.00> 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<NO_6_BYTE>

da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
da1: <SanDisk Extreme 0001> 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<NO_6_BYTE>

Thanks for reading,

bob prohaska
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180626070126.GB17293>