RPI3 swap experiments, was Re: GPT vs MBR for swap devices

[bob prohaska]

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