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

Mark Millard marklmi at yahoo.com
Tue Jun 26 14:38:07 UTC 2018

On 2018-Jun-26, at 3:40 AM, Jamie Landeg-Jones <jamie at catflap.org> wrote:

> Warner Losh <imp at bsdimp.com> 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.
> [ ... ]
>> 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...
> For what it's worth, I had the same errors on a rpi3 a few months ago, and
> eventualy gave up "to sort it tomorrow" - it hasn't been powered on since, but
> I still want to get it working.
> The system would run fine, but give the vfs errors on the 128GB usb thumb
> drive every week - like clockwork, when one of the heavier periodic jobs ran.
> I was running the latest CURRENT at the time. The thumb drive works fine elsewhere,
> and indeed - did on the same hardware when I test installed a linux install,
> and thrashed the hell out of it.
> I'll fire it up again - hopefully I'll still have the same results, and with 2
> of us, we may find the cause quicker.
> (n.b. i never had swap errors, but I can't recall if i ever configured swap on the usb
> drive)

The presence of the errors is a confounding variable for the other
issues being looked into.

It would likely be better for the effort to be split:

A) Looking into the drive errors and what range of contexts
   get them, hoping to find something to fix the issue (such
   as by adding a quirk).

B) Looking into the swapping and Out Of Memory process killing
   --but absent such errors being involved. (For now this might
   require a different instance of the same type of device
   or a different type of device.)

It seems too complicated to be investigating (B) but in a
context with the drive errors also involved.

As I remember, Bob P. Did reproduce drive errors even without
the problem drive being used for swapping. This too suggests
(A) as separate activity.

If only one of the 2 is targeted first, (A) may be the
better one to pursue for those with reproducible examples.

For those with contexts that lack the drive errors, (B)
activity might show a contrasting behavior for lack of drive
errors --or the behavior might be reproduced. Cross checking
on if drive errors started showing up would be appropriate.

An intersting question for (A) might be if some drive benchmark
program(s) might reproduce the drive errors. If such was found,
the context for reproduction would be far simpler than buildworld
buildkernel use.

Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

More information about the freebsd-arm mailing list