GPT vs MBR for swap devices
bob prohaska
fbsd at www.zefox.net
Wed Jun 20 02:32:41 UTC 2018
On Tue, Jun 19, 2018 at 06:44:00PM -0700, Mark Millard wrote:
> bob prohaska fbsd at www.zefox.net wrote on
> Tue Jun 19 21:59:50 UTC 2018 :
>
> > One more test has completed. The Pi3 was configured with 1 GB swap on the
> > microSD card. It was expected to run out of swap and start the OOM assassin.
> > Instead, it ran until the swap usage hit a little over 80% and then
> > traffic with da0d (/usr, likely /usr/obj) got stuck.
> >
> > Traffic to da0d remained stuck for several sampling cycles, swap
> > usage dropped to a few percent, and I finally pulled the plug when the
> > debugger would not start. The console messages are of a sort seen before
> > and might suggest hardware trouble, but after rebooting and fsck the machine
> > seems just fine and is running another test. It's completely unclear to me
> > what triggered the USB stoppage.
> >
> > The relevant files are at
> >
> > http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/
> >
> > I hope they're useful.
>
> where the referenced place includes this console messaging in
> one of the files:
>
> > r = 5
> > :48 www init[51271]: can't exec getty '/usr/libexec/getty' for port /dev/ttyu0: Input/output error
> > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00
> > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00
> > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> > (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
> > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00
> > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> > (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain
> > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00
> > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> > (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain
> > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00
> > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted
> > g_vfs_done():da0d[WRITE(offset=20709376, length=4096)]error = 5
> > g_vfs_done():da0d[WRITE(offset=36764549120, length=32768)]error = 5
> > g_vfs_done():da0d[WRITE(offset=36862820352, length=32768)]error = 5
> > g_vfs_done():da0d[WRITE(offset=36984651776, length=65536)]error = 5
> > g_vfs_done():da0d[READ(offset=39455948800, length=32768)]error = 5
> > g_vfs_done():da0d[WRITE(offset=51207864320, length=32768)]error = 5
> > g_vfs_done():da0d[WRITE(offset=51207962624, length=32768)]error = 5
> > g_vfs_done():da0d[WRITE(offset=51228348416, length=4096)]error = 5
> > g_vfs_done():da0d[WRITE(offset=65536, length=4096)]error = 5
> > :45 www init[51281]: can't exec getty '/usr/libexec/getty' for port /dev/ttyu0: Input/output error
>
>
> As I understand this it indicates that the drive /dev/da0 is
> failing to execute some requests and returning error status
> information to FreeBSD.
>
> I view this as evidence that you need to get the materials
> off that drive and need to quit using the drive that was
> /dev/da0. (Or similar status for connections or other stages
> between the rpi3 and /dev/da0 [inclusive of both].)
>
Possibly. An alternative to which I subscribe (for the moment)
posits that FreeBSD has started talking rubbish to da0 and da0
is responding appropriately. The problem dissapears on reboot.
> One classic problem, when not using a powered hub, is the rpi3
> sometimes not providing sufficient quality power to the USB
> device(s) plugged in.
>
A powered hub is running da1 and da2. Most important, rebooting and
fsck clears the difficulty. If that didn't happen I'd agree with you.
> Whatever the case, with the above happening, it is not reasonable
> to expect things to work.
>
Indeed! 8-)
Thanks for reading,
bob prohaska
More information about the freebsd-arm
mailing list